Reading HTTP Headers

What headers actually are

Every HTTP exchange carries metadata beside the body: key-value pairs describing the content, the connection, and how each side should behave. Request headers describe the client and what it wants; response headers describe the content and how it may be used. They are the protocol's instruction layer — and because browsers apply them silently, most users never see the decisions being made on their behalf.

Caching decoded: the directives that matter

Cache-Control is the modern control surface, and four directives cover most of reality. max-age sets freshness in seconds — until it expires, browsers serve stored copies without asking. no-cache does not mean never store; it means revalidate every time. no-store means never cache at all. And must-revalidate forbids serving stale content under any circumstance. Most 'why is my update not showing' mysteries resolve to one of these four behaving as configured.

ETag and Last-Modified: the revalidation pair

When cached content expires, revalidation asks the server 'has this changed?' using ETag (a content fingerprint) or Last-Modified. Unchanged content returns 304 Not Modified — headers only, no body — which is the web's cheapest response. Sites with neither header force full re-downloads on every revalidation, a quiet performance tax visible the moment you look at the headers.

The security header checklist

Four headers form the baseline every site should send. Content-Security-Policy restricts what the page may load and execute — the strongest single XSS mitigation. Strict-Transport-Security forces HTTPS on return visits. X-Content-Type-Options stops MIME-sniffing surprises. And frame protection (CSP frame-ancestors or X-Frame-Options) prevents clickjacking. Running the checklist against a site takes seconds and reveals its security maturity immediately.

Content-Type: the small header with big consequences

Content-Type tells consumers how to interpret the body — and mismatches cause real failures: JSON served as text breaks strict clients, missing charset declarations invite encoding chaos, and wrong types on uploads get rejected by APIs before the content is even read. When an integration fails mysteriously, the Content-Type exchange between both sides is a first-line suspect.

CORS headers: why your fetch fails

Cross-origin requests require the server's explicit permission, expressed in Access-Control-Allow-Origin and friends. The famous CORS error is the browser enforcing that permission system. Reading the response headers tells you exactly what was allowed and why your origin was not — which turns a console error into a server configuration conversation.

Diagnostic patterns: symptom to header

The professional mapping. Updates not appearing: check Cache-Control and Expires for long freshness. Pages failing inside iframes: frame protection headers. Downloads arriving with wrong names or types: Content-Disposition and Content-Type. Requests slow but content small: missing compression headers. Each symptom points at a header family, and the viewer makes checking each one seconds.

What request headers say about you

Your browser announces plenty: User-Agent, accepted languages, accepted content types, sometimes cookies. Privacy-conscious users recognize the fingerprinting surface here. The practical value of seeing your own request headers is calibration — knowing what every request carries before deciding which extensions and settings to change.

Viewing from your own vantage point

Header inspection tools differ by where they observe from. A server-side check sees what the server sends in the abstract; your browser sees what your client receives, with your cookies, your negotiated encodings, your cache state. For 'why does this behave differently for me' questions, only the browser-side view answers truthfully.

The security-header checklist worth knowing

Response headers carry the site's defensive posture, and viewing them is the fastest audit available. The core list: Content-Security-Policy restricting script sources; Strict-Transport-Security forcing HTTPS; X-Content-Type-Options set to nosniff; X-Frame-Options or frame-ancestors preventing clickjacking; and Referrer-Policy limiting leaky referrers. A header viewer shows within seconds which of these exist and which are missing — and missing is the common finding. The output makes a concrete remediation list: each absent header is one config line away in most server setups.

Cache headers decoded

Caching behavior lives entirely in headers, and misconfiguration causes the two classic failure modes: stale content users cannot refresh, and uncached assets that waste bandwidth. The fields to read: Cache-Control directives (max-age, no-store, must-revalidate), the ETag fingerprint for conditional requests, and Expires as the legacy fallback. The interpretation skill: max-age of zero with must-revalidate means re-check every time but accept conditional hits; no-store means no caching at all. Viewing real responses teaches this vocabulary faster than documentation, because each directive arrives attached to a concrete asset you can reason about.

Cookies and redirects: headers as the debugging lens

Login loops and redirect chains are header problems wearing behavior costumes. The viewer exposes the sequence: each 301/302 response's Location header chains to the next hop, so an infinite loop reads as repeated identical locations. Cookie issues appear in Set-Cookie attributes — a cookie without Secure on an HTTPS site, or SameSite blocking it in cross-site requests. Walking the header trail hop by hop converts 'login is broken' into 'the redirect at hop three points at the wrong host', which is a fixable finding.

Reading response headers for real problems

Headers answer three operational questions, and knowing which one you are asking focuses the reading. Caching questions are answered by Cache-Control, ETag, and Age: an asset that should be immutable but carries no-store is being re-downloaded on every visit, and a personal page cached by a shared proxy is a privacy bug. Security questions are answered by Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security, and frame-ancestors directives; their absence on a production site is itself a finding. Redirect questions are answered by the status line plus Location, and chains of more than two hops usually indicate a misconfiguration worth fixing.

Compression headers are the most commonly misread pair. Content-Encoding: gzip tells you the wire format, while Vary: Accept-Encoding tells caches they must keep separate copies per encoding. A CDN serving gzipped content without the Vary header can hand a compressed body to a client that did not ask for it — rare, but exactly the class of bug a header inspection surfaces.

Remember what headers cannot tell you: they describe the transport, not the payload. A 200 with correct headers can still carry a broken page, and CORS errors visible in a browser console are about header negotiation between two origins, which makes a header viewer the right instrument for diagnosing them. Check the Access-Control-Allow-Origin value against the requesting origin exactly; * and credentials do not mix.

Common mistakes with this tool

• Debugging stale content without ever checking Cache-Control.
• Judging a site's security without running the four-header checklist.
• Assuming a CORS error is a client bug instead of reading the allow headers.
• Inspecting headers from the server's perspective when the problem is client-specific.

Frequently asked questions