HTTP Response Headers Explained: What Your Server Is Actually Telling Browsers

When your browser loads a page, the actual HTML is only part of what comes back. Wrapped around it is a set of HTTP response headers -- metadata the server sends before (and alongside) the content itself. They control caching, tell the browser what's safe to do with the page, and often leak more about your server stack than you'd want. Here's what's actually in there.

Caching headers decide how often the browser re-asks

Cache-Control is the header doing the real work here. A value like max-age=3600 tells the browser it can reuse the response for an hour without checking back. no-store means don't cache at all. ETag and Last-Modified work differently -- they let the browser ask "has this changed since I last saw it?" and get a cheap 304 Not Modified instead of re-downloading everything. Get these wrong and you either serve stale content or make users re-download assets that haven't changed.

Security headers are opt-in, not automatic

Browsers don't assume a page wants strict security -- the server has to say so explicitly:

• Content-Security-Policy restricts what scripts, styles, and resources a page is allowed to load, which is one of the more effective defenses against cross-site scripting.
• Strict-Transport-Security tells the browser to only ever connect over HTTPS for this domain going forward, even if someone types http://.
• X-Content-Type-Options: nosniff stops the browser from guessing a file's type based on content, which closes off a class of MIME-confusion attacks.
• X-Frame-Options controls whether your page can be embedded in an iframe on another site, which is the main defense against clickjacking.

A site missing all of these still works fine for regular users -- but it's leaving defenses on the table that cost nothing to enable.

Some headers reveal more than they should

Server and X-Powered-By often announce the exact software and version running behind the site (nginx/1.18.0, Express, PHP/8.1.2). That's not a vulnerability by itself, but it does hand an attacker a head start on knowing what known exploits to try. Plenty of security guides recommend stripping or genericizing these headers for that reason.

Redirects and content type live in headers too

A Location header is what actually drives a redirect -- the 3xx status code alone doesn't tell the browser where to go next. Content-Type tells the browser whether to render a response as HTML, treat it as JSON, or download it as a file, and getting it wrong is a common source of pages rendering as garbled text or downloading when they shouldn't.

Check any site's headers directly

You don't need browser dev tools open to see this -- point a URL at the HTTP Header Checker and it shows you the full response header set for any site, which is the fastest way to see whether a security header is actually being sent or just assumed.