How to Read HTTP Headers When Debugging a Site

Use this guide when a page “loads but behaves wrong”: stale HTML, a CORS error in the console, a redirect loop, or a cookie that never sticks. Type only URLs you are allowed to fetch.

Request versus response

The request is what a client sends (GET /path, Origin, Cookie, Accept). The response is what the server or CDN returns (200, Location, cache-control, set-cookie). Most “why is this cached” and “why did the browser block this fetch” questions are answered on the response - plus the status line.

A third-party viewer sends its request, not yours. It will not include your session cookie. That is why an authenticated JSON endpoint may return 401 or a login HTML page in the viewer while it returns 200 in your app. That discrepancy is information: the resource is not public, or it varies on Cookie.

For a public marketing page or a documented API, the viewer’s view is usually close enough to debug cache and CORS. For a bank portal, use DevTools on a machine you control.

Cache headers that change what people see

Read these as a set, not as slogans:

• cache-control - max-age, no-store, private, s-maxage (shared caches / CDNs). no-store on HTML is common for app shells. max-age=31536000 on a fingerprinted JS file is normal.
• etag / last-modified - validators. A 304 means “use what you have.” If you deployed new HTML and users still see old markup, look here and at the CDN, not only at DNS.
• age - how long a shared cache has held the object.
• vary - which request headers change the cached variant (accept-encoding, origin, cookie). A missing vary: origin on a CORS response is a classic “works in one browser, poisoned cache in another” bug.

expires is the older HTTP/1.0 cousin. If both exist, cache-control wins in modern clients.

None of this requires a file upload. It does require a GET (or HEAD) to the public URL.

CORS and cookies: the two that break clients

CORS is decided with access-control-allow-origin (and friends) on the response to a cross-origin request, including the OPTIONS preflight. * cannot be paired with access-control-allow-credentials: true. If your SPA’s origin is not in that list, the browser hides the body from JavaScript even when the viewer shows 200.

Cookies show up as set-cookie: Secure, HttpOnly, SameSite, Domain, Path. SameSite=Lax is why a cross-site POST might not send the cookie. Domain=.example.com is why a cookie set on the apex appears on www. The viewer shows what the server tried to set on that response, not what is already in your jar.

If the problem is TLS rather than headers - name mismatch, expired leaf - switch to SSL Certificate Checker. That tool also sends the hostname.

Security headers that are either present or not

These do not rank a page. They constrain browsers:

• strict-transport-security - HSTS. Once a browser has seen it, HTTP upgrades for that host (and maybe includeSubDomains).
• content-security-policy - what scripts and frames are allowed. A report-only header (content-security-policy-report-only) is a dress rehearsal.
• x-frame-options / frame-ancestors - clickjacking mitigations.
• x-content-type-options: nosniff - stop MIME guessing.
• referrer-policy - how much of the URL leaks on navigation.

Absence is a finding for a checklist, not an automatic CVE. Presence with a broken policy (script-src * 'unsafe-inline' and a hole) can be worse than a missing header.

server and x-powered-by are fingerprints. Useful for “are we hitting nginx or the app,” not for security theater.

How to pull a live public response

1. Use a URL you are allowed to request. Public homepage: fine. Someone else’s /admin: do not.
2. Open HTTP Header Viewer and submit the URL. The hostname (and path) are sent so the remote host can answer.
3. Read the status and location first. A 301/302 chain is often the whole incident.
4. Then cache, then CORS, then set-cookie, then security headers.
5. Compare with DevTools on your own browser if the viewer’s network sits in another region or the CDN is doing A/B.

If the TCP/TLS layer never completes, headers will not appear. Check DNS with DNS Record Lookup and the certificate with SSL Certificate Checker first.

What headers will not tell you

They will not show the rendered DOM, the title tag, or Open Graph images. That is HTML; use Meta Tag Extractor and Open Graph Preview for the document. They will not measure LCP. They will not list every cookie the browser already has.

They also will not show a response that only exists after WebSocket upgrade or after a POST with a CSRF token you did not send.

Read the envelope on a URL you own

Open HTTP Header Viewer on a public URL you own or have permission to test. If HTTPS itself is the failure, use SSL Certificate Checker. For the HTML head rather than the envelope, How to Audit Meta Tags is the sibling job.