HTTP Headers Explained: How to Read Response Headers Like a Pro

Every HTTP response your browser receives includes a set of headers — key-value pairs that tell the browser how to handle the response. Understanding these headers helps you debug caching issues, identify security gaps, and configure CORS correctly. Use brevio HTTP Headers Decoder to paste headers from DevTools and decode them instantly in your browser.

What Are HTTP Response Headers?

Response headers are metadata attached to an HTTP response before the body. They are separate from the response body (the HTML, JSON, or file content) and invisible in the rendered page. The browser reads them to decide how to cache the response, whether to block it for security reasons, and how JavaScript running on the page can interact with cross-origin resources.

To see response headers for any request: open DevTools (F12 on Windows/Linux, ⌘⌥I on Mac), go to the Network tab, click any request, and select the Headers sub-tab. The response headers section shows exactly what the server sent.

The Five Header Categories

1. Security Headers

Security headers instruct the browser to enforce restrictions that protect users. They are server-side controls — you configure them in your web server or CDN, not in your application code.

• Strict-Transport-Security (HSTS): Forces HTTPS for all future visits. max-age=31536000 means one year. Once set, the browser refuses HTTP connections even if the user types http://.
• Content-Security-Policy (CSP): Restricts which scripts, styles, images, and iframes the page can load. The most powerful XSS prevention mechanism available to web developers.
• X-Frame-Options: Prevents the page from being embedded in an <iframe>. DENY blocks all framing; SAMEORIGIN allows same-origin frames only. Prevents clickjacking attacks.
• X-Content-Type-Options: nosniff — Prevents browsers from guessing the content type by inspecting the body. Without this, a malicious HTML file served as text/plain could still be executed as HTML.
• Referrer-Policy: Controls how much of the current page URL is included in the Referer header of outgoing requests. strict-origin-when-cross-origin is a sensible default.
• Set-Cookie: Sets a cookie. Key security attributes: Secure (HTTPS only), HttpOnly (not accessible via JavaScript), SameSite=Strict (prevents CSRF).

2. Caching Headers

Caching headers tell browsers and proxies how long to store a response before requesting a fresh copy.

• Cache-Control: The primary caching directive. Common values: max-age=3600 (cache for 1 hour), no-cache (always revalidate before using), no-store (never cache), public (CDN-cacheable), private (browser-only).
• ETag: A fingerprint of the current resource version. The browser sends it back as If-None-Match — if the resource unchanged, the server returns 304 Not Modified instead of the full body.
• Last-Modified: The date the resource was last changed. Works with If-Modified-Since for conditional requests.
• Vary: Lists request headers that affect the response. Vary: Accept-Encoding tells caches to store separate copies for gzip and non-gzip clients.

3. Content Headers

• Content-Type: The media type of the response body. application/json; charset=utf-8 for APIs, text/html; charset=utf-8 for web pages.
• Content-Length: The size of the response body in bytes. Browsers use this to show download progress.
• Content-Encoding: Compression applied to the body (gzip, br for Brotli, zstd). The browser decompresses automatically before rendering.
• Transfer-Encoding: chunked — The server sends the body in pieces of varying size. Used for streaming responses where the total size is unknown.

4. CORS Headers

Cross-Origin Resource Sharing (CORS) headers control whether JavaScript on one origin can read responses from another origin.

• Access-Control-Allow-Origin: Which origins may read the response. * allows any origin, but cannot be used with credentialed requests.
• Access-Control-Allow-Methods: HTTP methods permitted in cross-origin requests.
• Access-Control-Allow-Headers: Request headers that cross-origin requests may include.
• Access-Control-Max-Age: How long (seconds) the browser can cache the preflight response.

5. Other Headers

• Server: Identifies the web server software. Often obscured for security.
• X-Powered-By: Identifies the application framework. Commonly removed to avoid exposing the tech stack to attackers.
• Location: The redirect URL for 3xx responses.

Security Headers Checklist

Caching Strategy: Cache-Control and ETag Together

The most effective caching strategy combines both headers. Cache-Control: max-age=3600 tells the browser to use the cached copy for one hour without checking. After one hour, the browser sends a conditional request with If-None-Match: "etag-value". If the resource has not changed, the server returns 304 Not Modified — saving the full response body transfer while still detecting changes.

For static assets with content-based filenames (e.g. main.abc123.js), use Cache-Control: max-age=31536000, immutable — one year, never revalidate. The filename changes on every build, so the old URL is effectively never requested again.

CORS Preflight Explained

Before sending a cross-origin request with a non-simple method (PUT, DELETE) or custom headers (Authorization), the browser sends an OPTIONS preflight request. The server must respond with appropriate Access-Control-Allow-* headers. If the preflight fails, the actual request is never sent. Use Access-Control-Max-Age to cache preflight results and avoid the round-trip on every request.

How to Verify Headers with DevTools

1. Open DevTools. Press F12 or ⌘⌥I, then go to the Network tab.
2. Load the page or trigger a request.
3. Click a request row, then select the Headers tab.
4. Scroll to Response Headers. Copy and paste them into brevio HTTP Headers Decoder to see descriptions for each one.

Common Mistakes

• Missing HSTS. Without HSTS, a user who types http://yoursite.com makes an insecure initial connection before being redirected to HTTPS.
• CORS wildcard with credentials. Access-Control-Allow-Origin: * does not work when the request includes cookies or Authorization headers. The server must echo the specific origin.
• Cache-Control: no-cache vs no-store. no-cache still stores the response — it just requires revalidation before use. no-store prevents caching entirely. Use no-store for authentication tokens and sensitive account data.
• X-Powered-By left enabled. Exposing your framework version (Express/4.18.2) helps attackers target known CVEs. Disable it in production.