<h2 id="what-this-post-covers">What this post covers</h2>
<p>In this short post we look at the Cookie header. If you already know the five request verbs, and you can name Content-Type, Accept, and Authorization, you are ready.</p>
<p>This is for juniors. Who adds Cookie, a look at <code>GET /api/blogs</code>, Cookie versus Authorization, matching rules, a token in a cookie, then Postman. No JWT theory. No CORS. When you finish, you can say the line below.</p>
<p class="bd-statement">The browser adds Cookie on the page. You do not set it in fetch. Postman can still send it if you paste it. It is not Authorization.</p>

<h2 id="the-browser-adds-cookie">The browser adds Cookie</h2>
<p>Picture a logged-in admin page for a blog API. It calls <code>GET /api/blogs</code>. You did not type a Cookie header in fetch. The request still has one.</p>
<p>On a first visit, there is no session cookie. After login, the server can answer <code>Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax</code>. The browser stores that note. The next GET from that tab already carries it. WHATWG Fetch lists Cookie as a forbidden request header, so page JavaScript cannot set it (MDN, 2026).</p>
<pre><code>GET /api/blogs
Cookie: session=abc</code></pre>
<p class="bd-statement">On the page, the browser writes Cookie. Fetch does not.</p>

<h2 id="two-jobs-then-matching-cookies">Two jobs, then matching cookies</h2>
<p>A session cookie does not become Bearer. Some servers still want Authorization on a delete even when a cookie is present.</p>
<div class="bd-grid">
  <div class="bd-card-muted">
    <p><strong>Wrong turn</strong></p>
    <p>Treat <code>Cookie: session=abc</code> as if it were <code>Authorization: Bearer</code>.</p>
  </div>
  <div class="bd-card">
    <p><strong>Two jobs</strong></p>
    <p><code>Cookie</code> is the browser’s note. <code>Authorization: Bearer</code> is a token you send.</p>
  </div>
</div>
<figure>
  <img src="https://techtipsbymoh.tor1.cdn.digitaloceanspaces.com/techtipsbymoh-production/blogs/the-cookie-header/ee39527c02e2493f8d76294ce24fbecd_01-cookie-not-authorization.png" alt="A baked cookie on a teal-rimmed podium beside a separate padlock on its own podium, with a split ring between them.">
  <figcaption>A baked cookie and a separate brass token on one cream letter.</figcaption>
</figure>
<p>The browser sends every cookie that matches this request, in one header. The line can be <code>Cookie: session=abc; theme=dark</code>. That is not every cookie on the computer.</p>
<p>The matching rules come from the server on <code>Set-Cookie</code>. The browser stores them. They do not come back as extra request headers. A fuller login response can look like this:</p>
<pre><code>HTTP/1.1 200 OK
Set-Cookie: session=abc; Domain=www.example.com; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=86400</code></pre>
<div class="table-responsive scroll-type-one">
  <table class="blog-table">
    <thead>
      <tr><th>Attribute</th><th>Meaning</th></tr>
    </thead>
    <tbody>
      <tr>
        <td>Domain</td>
        <td>Optional. Set it to share the cookie across hosts on that domain. Omit it: host-only, the exact host that set it.</td>
      </tr>
      <tr>
        <td>Path</td>
        <td>Optional. <code>Path=/admin</code> stays off <code>GET /api/blogs</code>. Omit it: the path of the URL that set the cookie.</td>
      </tr>
      <tr>
        <td>Secure</td>
        <td>A flag. The cookie only goes on HTTPS.</td>
      </tr>
      <tr>
        <td>HttpOnly</td>
        <td>A flag. Page JavaScript cannot read it with <code>document.cookie</code>.</td>
      </tr>
      <tr>
        <td>SameSite</td>
        <td><code>Lax</code>, <code>Strict</code>, or <code>None</code>. Our example used Lax. Lax and Strict stay off most calls from another site.</td>
      </tr>
      <tr>
        <td>Max-Age / Expires</td>
        <td>Optional. How long the cookie lives. Omit both and it is a session cookie. Expired cookies are dropped.</td>
      </tr>
    </tbody>
  </table>
</div>
<p>The short login line we used earlier omitted Domain, Path, and Max-Age. That is valid. SameSite is still Lax. The next GET only sends the name and value:</p>
<pre><code>GET /api/blogs
Cookie: session=abc</code></pre>
<p>A cookie on <code>Path=/</code> even rides on an image. Same site: fetch sends matching cookies by default. Another site: you need <code>credentials: include</code>.</p>
<p class="bd-statement">Matching cookies ride along. Authorization still has its own job.</p>

<h2 id="a-token-in-a-cookie">A token in a cookie</h2>
<p>What if the bearer value lives in a cookie? Real pattern. It changes which header carries login. JavaScript can read localStorage and set <code>Authorization: Bearer</code>. The browser will not add that header.</p>
<p>Or login sets <code>Set-Cookie: access=…; HttpOnly</code>. The next GET is Cookie. Usually no Authorization. The server must accept Cookie. That is cookie auth, not bearer hidden in a cookie.</p>
<pre><code>GET /api/blogs
Cookie: access=…</code></pre>
<p class="bd-callout bd-callout-warn">HttpOnly, Secure, and SameSite help. The cost is every matching request. CSRF is the risk. A cookie that is not HttpOnly is worse than localStorage: a script can steal it, and another site can try to use it.</p>

<h2 id="how-postman-still-sends-it">How Postman still sends it</h2>
<p>You cannot set Cookie in fetch. You cannot read an HttpOnly cookie with <code>document.cookie</code>. HttpOnly means this page’s JavaScript cannot see it. It does not mean nobody can see it.</p>
<p>In Postman, api.http, or curl, you are the client. You may send Cookie. Log in there and read Set-Cookie, or copy the value from DevTools, Application, Cookies. Then paste it.</p>
<pre><code>GET /api/blogs
Cookie: session=abc</code></pre>
<div class="table-responsive scroll-type-one">
  <table class="blog-table">
    <thead>
      <tr><th>Who</th><th>Read HttpOnly?</th><th>Send Cookie?</th></tr>
    </thead>
    <tbody>
      <tr><td>fetch / page JS</td><td>No</td><td>No. The browser attaches it.</td></tr>
      <tr><td>DevTools</td><td>Yes, you can see it</td><td>You copy the value</td></tr>
      <tr><td>Postman / api.http / curl</td><td>Yes, from Set-Cookie or DevTools</td><td>Yes, you type the header</td></tr>
    </tbody>
  </table>
</div>
<figure>
  <img src="https://techtipsbymoh.tor1.cdn.digitaloceanspaces.com/techtipsbymoh-production/blogs/the-cookie-header/4feba8343717463c94ff8e611f7aad55_02-browser-and-postman.png" alt="Two dark screens: a browser page on the left and an API-tool panel with a key and settings on the right, linked by a small node.">
  <figcaption>A cookie jar and a clipboard are two different clients.</figcaption>
</figure>
<p class="bd-statement">The frontend never gives Postman the token. Some servers keep Cookie for the website and Authorization Bearer for Postman. That second door is optional.</p>

<h2 id="what-you-can-say">What you can say</h2>
<p>The same path is in the companion tip, <a href="/tips/the-cookie-header" rel="noopener noreferrer">The Cookie header</a>. Earlier posts: <a href="/blog/request-headers" rel="noopener noreferrer">Request headers</a> and <a href="/blog/token-in-the-header" rel="noopener noreferrer">Token in the header</a>. This post was only Cookie.</p>
<p class="bd-statement">The browser adds Cookie on the page. You do not set it in fetch. Postman can still send it if you paste it. It is not Authorization.</p>

For juniors who know the common request headers: the browser adds Cookie on the page. You do not set it in fetch. Postman can still paste it.

The Cookie header, not Authorization

The Cookie header

For juniors who know request headers: keep the bearer token in Authorization, not in the blog JSON, and see why a delete with no body still needs it.

Why the bearer token stays in the header

Token in the header

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.

The Cookie header

More from the blog.

Token in the header

Request headers

Five request verbs