Blog
3 min read

HTTP Headers Explained: The Hidden Part of Every Request

Every web request and response carries headers — extra information about the content, the client, authentication, caching and security. The headers you'll meet most (Content-Type, Authorization, Cookie, Cache-Control, CORS), how to see them in DevTools, and how to set them.

When your browser asks a server for a page, and when the server answers, both send more than the content itself. They send headers: lines of extra information about the request or response.

GET /api/orders HTTP/1.1
Host: shop.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...
User-Agent: Mozilla/5.0 ...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Set-Cookie: session=abc123; HttpOnly; Secure

Each header is a Name: value pair. Names aren't case-sensitive.

Seeing headers yourself

Open DevTools (F12) → Network tab → reload → click any request. You'll see Request Headers and Response Headers. This is one of the most useful debugging habits there is. (Browser developer tools)

From the terminal:

curl -I https://example.com          # response headers only
curl -v https://example.com          # everything

(What is curl?)

Request headers you'll meet

Header What it says
Host Which website on this server you want
Content-Type Format of the body you're sending (application/json)
Accept Formats you'd like back
Authorization Credentials — often Bearer <token> (API authentication methods)
Cookie Cookies the browser has for this site (Cookies explained)
User-Agent What browser or program is asking
Origin Which site a cross-origin request came from
Idempotency-Key Lets the server spot duplicate requests (Idempotency keys)

Response headers you'll meet

Header What it says
Content-Type Format of the response body
Set-Cookie Store this cookie
Cache-Control Whether and how long to cache (HTTP caching headers)
Location Where to go, for redirects (301 vs 302)
Access-Control-Allow-Origin Which other sites may read this (CORS) (CORS errors explained)
Strict-Transport-Security Always use HTTPS (What is HSTS?)
Content-Security-Policy Which scripts and resources may load (CSP guide)
Retry-After When to try again (with 429 or 503)

Headers that cause bugs

  • Missing Content-Type: application/json when sending JSON → the server can't read the body, so req.body is empty.
  • Wrong Content-Type on the response → the browser treats JSON as a download, or HTML as text.
  • Missing CORS headers → "blocked by CORS policy" in the console.
  • Cookies not sent → SameSite, Secure or domain settings on the Set-Cookie header don't match. (CSRF and SameSite)
  • Caching headers too aggressive → users see old versions after a deploy. (Hard refresh and cache)

Setting headers

When making a request (fetch):

await fetch('/api/orders', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${token}`,
  },
  body: JSON.stringify(order),
})

In an Express response:

res.set('Cache-Control', 'no-store')
res.json(data) // also sets Content-Type: application/json

For a whole site, security headers are often set in the web server or reverse proxy (Nginx, Caddy) or the framework config. (HTTP security headers)

Custom headers

You can invent your own, like X-Request-Id for tracing a request through logs. Browsers won't send custom headers cross-origin without a CORS "preflight" check, which is part of why APIs on another domain feel fiddly.

The summary

  • Headers are the metadata on every request and response.
  • Content-Type, Authorization, Cookie, Cache-Control and CORS headers cause most header-related bugs.
  • Check them in DevTools → Network, or with curl -v.

EasySpawn puts your app behind a reverse proxy with HTTPS and sensible security headers already in place. See how it works or join the waitlist.

Related: HTTP Status Codes Explained · HTTP Security Headers Explained · CORS Errors Explained · GET vs POST

Keep reading