📡 HTTP Headers Checker

About HTTP Response Headers

Every time a browser asks a web server for a page, the server answers with a status line, a block of response headers and then (usually) the page itself. The headers are the instructions: they tell the browser what the content is, how long it may be cached, whether other sites are allowed to embed it, and which browser features the page is permitted to use. Nearly every caching bug, mixed-content warning and clickjacking hole shows up here first.

This tool fetches the URL from our server, so you see exactly what an outside client receives — no browser extensions, no service worker, no local cache in the way. It sends a HEAD request first and falls back to GET if the server rejects HEAD with 405 or 501, which a surprising number of application servers still do.

Why the redirect chain matters

Most tools follow redirects silently and only show you the destination. That hides the interesting part. Each hop costs a full round trip — DNS, TCP, TLS, request, response — so a chain of three or four redirects can add hundreds of milliseconds before a single byte of content moves. Chains are also where things quietly break:

• A hop that drops back to plain HTTP exposes the request, and any cookie sent with it, to anyone on the network.
• Mixing 301 and 302 confuses search engines about which URL is canonical; only 301 and 308 signal a permanent move.
• 307 and 308 preserve the request method and body; 301, 302 and 303 let the browser downgrade a POST to a GET, which silently loses form data.
• Redirect loops (A → B → A) usually mean a rewrite rule and a canonical-domain rule are fighting each other.
• Redirecting to a different host loses cookies scoped to the original domain, which is a common cause of "logged out on refresh".

We follow up to ten hops manually and show the status code, timing and Location value for every one, so you can see precisely where the request goes and where it costs you.

The six security headers we audit

These are the headers that turn browser features into defences. Each one mitigates a specific, well-understood class of attack.

• Strict-Transport-Security (HSTS) — after one HTTPS visit, the browser refuses to speak plain HTTP to your host for the stated max-age. This kills SSL-stripping attacks on public Wi-Fi, where an attacker downgrades the first request and reads everything after it. Preload lists require at least max-age=31536000; includeSubDomains; preload.
• Content-Security-Policy (CSP) — an allowlist of where scripts, styles, images, fonts and frames may come from. It is the strongest single defence against cross-site scripting: even if an attacker injects a <script> tag, the browser refuses to run it unless the source is allowed. A nonce- or hash-based policy with 'strict-dynamic' is far stronger than an allowlist of domains.
• X-Frame-Options — stops other sites loading your pages inside a frame. Without it, an attacker can overlay an invisible copy of your site on their own and trick a logged-in user into clicking your buttons — clickjacking. The modern equivalent is the CSP frame-ancestors directive, which supersedes this header where both are present.
• X-Content-Type-Options — the single value nosniff stops the browser guessing a file's type from its contents. Without it, a user-uploaded file served as text/plain can be sniffed as JavaScript and executed in your origin. Nothing other than nosniff has any effect.
• Referrer-Policy — decides how much of the current URL is sent to third parties in the Referer header. Paths and query strings routinely contain reset tokens, order numbers and internal identifiers; a policy of strict-origin-when-cross-origin or no-referrer keeps them from leaking to every analytics script and outbound link.
• Permissions-Policy — switches off powerful browser features (camera, microphone, geolocation, payment, USB) for the page and everything it embeds. Its main value is defensive: a compromised third-party script or embedded iframe cannot ask for the camera if the policy has already denied it. It replaces the obsolete Feature-Policy header.

The grade is a blunt instrument: A for all six present, down to F for one or none. It is a presence check, not a policy analysis — Content-Security-Policy: default-src * is a fully present header that protects against nothing at all. Treat a good grade as "nothing obvious is missing", then read the actual values.

Caching headers worth reading

• Cache-Control — the authority on caching. max-age is browser lifetime in seconds, s-maxage overrides it for shared caches (CDNs), no-store forbids caching entirely and immutable promises the file will never change.
• ETag and Last-Modified — validators. When a cached copy goes stale the browser revalidates with these and can be told "304 Not Modified", saving the download but not the round trip.
• Vary — lists the request headers that change the response. Getting this wrong (or omitting it) is how one user's personalised page ends up cached and served to everyone.
• Age and X-Cache / CF-Cache-Status — how long a CDN has held the object and whether it was a HIT or a MISS. Useful for proving whether your CDN configuration is doing anything.

Things to bear in mind

• Headers can differ per URL. A CDN-cached asset and an application route on the same site often return completely different caching and security headers, so test the specific path you care about.
• Headers can differ per method. A server may return different headers to HEAD than to GET; we report which method produced the result.
• If the site sits behind a CDN or reverse proxy, some headers are added by that layer and never come from your application at all.
• Some sites reject requests from anything that is not a mainstream browser and will answer with 403 or a challenge page. That is a result about their bot filtering, not about your headers.
• For safety this tool refuses loopback, private and link-local addresses, so it cannot be used to probe machines on our internal network.