<h2 id="what-this-post-covers">What this post covers</h2>
<p>In this short post we are going to introduce the headers on a request. If you already know the five verbs, and that a body carries data, you are ready. You need three names, then one job each.</p>
<p>This is for juniors who can already name GET, POST, PUT, PATCH, and DELETE. We will name three request headers, give each one job on a blog API, then cover four notes about every request and the token leak. You do not need HTTP header theory yet. When you finish, you can name what each of these three does.</p>
<p class="bd-statement">You need three names, then one job each.</p>

<h2 id="three-names-first">Three names first</h2>
<p>You will see these names on a blog API, on a request like <code>POST /api/blogs</code> with a body of blog fields. The verb says what to do. The URL says which blog. The body carries the data. Headers carry the information about the request.</p>
<p>The three names come first, before any job.</p>
<ul class="bd-pills">
  <li class="bd-pill">Content-Type</li>
  <li class="bd-pill">Accept</li>
  <li class="bd-pill">Authorization</li>
</ul>
<p>These three are the most common. They are not the only ones. A request can carry more headers. Those stay out of this post. Next you get one job each.</p>

<h2 id="one-job-each">One job each</h2>
<p>The only app in this post is a blog API. The paths stay in the same family. The verb still names the job. Each header answers a different question about that request.</p>
<div class="table-responsive">
<table class="blog-table">
  <thead>
    <tr>
      <th>Header</th>
      <th>Job</th>
      <th>Example</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>Content-Type</code></td>
      <td>Format of the body you send</td>
      <td><code>POST /api/blogs</code> with <code>Content-Type: application/json</code> so the server reads that body as JSON.</td>
    </tr>
    <tr>
      <td><code>Accept</code></td>
      <td>Format you want back</td>
      <td><code>GET /api/blogs</code> with <code>Accept: application/json</code> so you get JSON, not an HTML page.</td>
    </tr>
    <tr>
      <td><code>Authorization</code></td>
      <td>Who is asking</td>
      <td><code>DELETE /api/blogs/42</code> with <code>Authorization: Bearer</code>, then a token. No token. The server answers 401. No delete.</td>
    </tr>
  </tbody>
</table>
</div>
<p class="bd-statement">Each header has one job on this blog API.</p>

<h2 id="headers-on-every-request-and-the-token-leak">Headers on every request, and the token leak</h2>
<p>Four last notes, then you are ready.</p>
<p>Headers go with every request, even <code>GET</code>. A body only rides on <code>POST</code>, <code>PUT</code>, and <code>PATCH</code>. Headers ride on all five verbs. MDN’s 2026 header pages treat Content-Type, Accept, and Authorization as request fields you can send whether or not a body is present.</p>
<p class="bd-callout bd-callout-warn">A common junior mistake is putting the token in the URL, like <code>/api/blogs/?token=abc123</code>. Browser history and server logs keep that URL. The token leaks.</p>
<div class="bd-grid">
  <div class="bd-card-muted">
    <p><strong>Wrong place</strong></p>
    <p><code>/api/blogs/?token=abc123</code></p>
  </div>
  <div class="bd-card">
    <p><strong>Right header</strong></p>
    <p><code>Authorization: Bearer</code>, then the token</p>
  </div>
</div>
<figure>
  <img src="https://techtipsbymoh.tor1.cdn.digitaloceanspaces.com/techtipsbymoh-production/media/uploads/419d339e-b262-4c5b-93be-67c158cae5cb/blog/17540b89236b4123bd61b60042413e3a_01-token-in-header.png" alt="Two cream envelopes on a dark table: one with a loose tag on the flap, one sealed with a wax seal. Labels: ?token=, Authorization.">
  <figcaption>The token belongs in the Authorization header, not in the URL.</figcaption>
</figure>
<p><code>Content-Type</code> describes the body you send. <code>Accept</code> describes the answer you want. Mixing them up is the second slip. MDN (2026) keeps those jobs apart: Content-Type names the media type you are sending; Accept names the types you can understand back.</p>
<p>These three are the common ones, not the full list. More headers exist. Later tips will cover the rest.</p>

<h2 id="what-you-can-say">What you can say</h2>
<p>You can hear the same three names in the companion tip, <a href="/tips/request-headers" rel="noopener noreferrer">Request headers</a>. The five verbs live in <a href="/blog/five-request-verbs" rel="noopener noreferrer">Five request verbs</a>.</p>
<p class="bd-statement">The body is the data. The headers tell the server how to read it, what to send back, and who is asking.</p>

For juniors who know the five verbs: name Content-Type, Accept, and Authorization, use each on a blog API, then keep the token out of the URL.

Content-Type vs Accept vs Authorization

Request headers

For juniors who can read a URL: name GET, POST, PUT, PATCH, and DELETE, use each on a blog API, then see why /api/blog/:id/delete is the wrong way.

Request headers

More from the blog.

Five request verbs