Understanding HTTP Headers

Every HTTP exchange begins with a negotiation you never see.

Before your browser receives a single byte of HTML, before the API returns any JSON, there's a conversation. Your client says: "Hi, I'm Chrome on macOS. I'd prefer JSON but I'll accept HTML. I speak gzip. Oh, and I have a cached copy from Tuesday—got anything newer?" The server responds: "Here's JSON, 4,847 bytes, compressed with gzip. Cache it for an hour. And by the way, you must use HTTPS from now on."

This conversation happens in headers. They're the small talk before the business meeting—the metadata that lets both sides agree on terms before any content changes hands.

The Shape of a Header

Headers are simple key-value pairs:

Content-Type: application/json
Cache-Control: max-age=3600
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Each header answers a specific question. Content-Type answers "what is this?" Cache-Control answers "how long can I keep it?" Authorization answers "who are you?"

Header names are case-insensitive (though conventionally written in Title-Case). Values may be case-sensitive depending on the header. That's about all the syntax you need to know.

Two Directions, Different Questions

Request headers are questions from client to server:

• "What formats do you have?" (Accept)
• "Who am I?" (Authorization)
• "Where did I come from?" (Origin, Referer)
• "Do you have anything newer than what I cached?" (If-Modified-Since)
• "What am I running?" (User-Agent)

Response headers are answers from server to client:

• "Here's what I'm sending" (Content-Type, Content-Length)
• "Here's how long to cache it" (Cache-Control, Expires)
• "Here are my security requirements" (Strict-Transport-Security)
• "Store this for later" (Set-Cookie)

The conversation goes both ways, but the questions are different.

What Headers Actually Do

Content description. Content-Type tells you what's in the box. Content-Length tells you how big. Content-Encoding tells you how it's compressed. Without these, your browser would have to guess—and guessing leads to security vulnerabilities and broken pages.

Caching. Cache-Control is perhaps the most impactful header for performance. A single directive—max-age=31536000—can eliminate millions of redundant downloads. ETag and Last-Modified let clients ask "has this changed?" instead of re-downloading everything.

Authentication. The Authorization header carries credentials. The server responds with WWW-Authenticate to say "I need credentials, and here's how to format them." This dance happens on nearly every API call you make.

Security. Strict-Transport-Security says "always use HTTPS." Content-Security-Policy says "only load scripts from these sources." X-Frame-Options says "don't let other sites embed me." These headers are your security policy, enforced by the browser.

Cross-origin access. CORS headers (Access-Control-Allow-Origin and friends) answer: "Is this website allowed to read my response?" Without them, JavaScript on one domain can't read responses from another—a fundamental browser security model.

The Flow

1. Your browser builds a request, adding headers about who it is and what it wants
2. Headers transmit as plain text, before the body
3. The server reads headers to understand the request
4. The server builds a response, adding headers about what it's sending and how to handle it
5. Your browser reads response headers to know how to process what follows

Between client and server, intermediaries—proxies, CDNs, load balancers—may add, remove, or modify headers. Some headers (like Connection) are "hop-by-hop," meaning they only apply to one link in the chain, not the whole journey.

Standard and Custom

Most headers are standardized by the IETF. Content-Type, Authorization, Cache-Control—these have defined meanings that every browser and server agrees on.

You can create custom headers for application-specific needs. The old convention was to prefix them with "X-" (X-Request-ID, X-Forwarded-For), but this is now deprecated. Modern practice: just use a descriptive name.

What People Get Wrong

Headers are not encrypted over HTTP. Your Authorization header travels in plain text unless you're using HTTPS. This is why HTTPS matters—not just for the body, but for the headers too.

Headers have size limits. Servers typically reject requests with headers larger than about 8KB. If you're stuffing too much into headers, you're doing it wrong.

Not all headers survive the journey. Intermediaries strip some headers. Hop-by-hop headers like Connection are intentionally not forwarded. The headers your server receives may not be the headers the client sent.

Seeing the Conversation

Every browser lets you watch this conversation happen:

1. Open Developer Tools (F12 or right-click → Inspect)
2. Go to the Network tab
3. Do something that triggers a request
4. Click any request to see its headers

You'll see both sides of the negotiation—what your browser asked for and what the server sent back. When authentication fails or caching misbehaves or CORS blocks your API call, the answer is usually in the headers.