HTTP Header Checker

How to Check a URL's Headers

Features

The Reply Behind the Reply

Open any page and your browser gets two things back: the content you asked for, and a stack of headers you never see — instructions about how long to cache the response, whether the connection can be downgraded to plain HTTP, which server handled the request, and a handful of rules meant to stop other sites from embedding or scripting against yours. Paste a URL above and this tool pulls that stack apart and lays it out, hop by hop if there were redirects, without you needing to open dev tools or reach for a terminal.

None of these headers show up in the rendered page itself, which is exactly why they get forgotten. A site can look, load and function perfectly while quietly missing every defensive header that would matter in an actual attack — there's no visual cue for it the way a broken layout or a 404 would announce itself.

Who Actually Reaches for This

• Developers — confirming an API or CDN endpoint returns the caching and security headers they just configured
• Security-conscious site owners — auditing HSTS, CSP and the rest before a public launch
• Freelancers and agencies — running a quick header audit as part of a client site handover
• SEO practitioners — checking cache behavior and redirect chains that affect crawl budget and page speed scores
• Students learning web security — seeing real header configurations from live sites rather than textbook examples

The Padlock Doesn't Tell You This

It's easy to treat the browser's padlock icon as a stamp of approval, but it only confirms one thing: the connection is encrypted and the certificate is valid. It says nothing about whether the response also blocks clickjacking, restricts which scripts can execute, or forces every future visit onto HTTPS instead of allowing a silent downgrade. Plenty of fully-encrypted sites carry a security score close to zero once you actually look at the headers — HTTPS and hardened headers are two separate layers, and only one of them is visible without a tool like this.

Six Headers Worth Memorizing

The score above isn't arbitrary — it counts six headers that, together, cover most of the browser-side attack surface a website exposes. Content-Security-Policy tells the browser exactly which scripts and resources are allowed to load, cutting off a huge class of injection attacks in one line. Strict-Transport-Security forces every future visit onto HTTPS, even if someone types the plain http:// address. X-Frame-Options stops your page from being loaded inside someone else's invisible iframe for clickjacking. X-Content-Type-Options keeps the browser from guessing a file's type in a way attackers can exploit. Referrer-Policy controls what leaks into the Referer header when a visitor clicks an outbound link. Permissions-Policy locks down camera, microphone and location access for scripts that have no business asking for them. None of them require rewriting your site — most go in one config block on your server or CDN.

Cache Headers Lie Less Than You'd Think

Say a change goes live and it "isn't showing up" for some visitors. Before assuming a deploy failed, check Cache-Control, Age and ETag on the asset in question — an Age that's still climbing means a CDN edge is serving a stale copy it hasn't invalidated yet, not that your deploy is broken. A missing ETag on something that should be cacheable usually points at caching being disabled for that path entirely, sometimes by accident during a config change. Reading these three headers correctly saves a lot of time spent debugging code that was never the problem.

Reading a Redirect Chain

A single click can hop through two or three redirects before landing anywhere — an old domain forwarding to a new one, an http:// address bounced to https://, a trailing slash getting normalized. Each one shows up in the redirect chain above with its own status code and destination, so you can see exactly where a link is routing before it reaches its final response. If a domain migration is behind the redirect, confirm the DNS Lookup Tool shows the new A record fully propagated first — checking headers on a domain still pointed at the old host will just show you the old answer.

Tips for Getting the Most Out of This

• Run the security score against production, not staging. Headers are frequently added to one environment and forgotten on the other, and staging results won't reflect what real visitors get.
• Check the domain visitors actually land on after every redirect — a CDN or reverse proxy sitting in front of your app can silently strip or override headers your app itself sends correctly.
• Re-run the check right after any Content-Security-Policy edit. A too-strict CSP breaks fonts, embeds or third-party scripts silently, and the failure shows up in a visitor's console, not yours.
• Compare before and after a CDN or hosting migration. Save the header dump beforehand using Copy All, then re-check after cutover to confirm nothing important got dropped in the switch.
• If you're auditing your own API, pair this with our JSON Formatter to read the response body alongside the headers you just pulled.

Where This Falls Apart

This checks from wherever the lookup service happens to be, not from a dozen global points of presence — it's a spot-check, not continuous monitoring. It can't reach a localhost address or anything sitting on a private network, since that's outside the reach of any public checking service. And on a shared or heavily-used connection, the free daily lookup allowance behind this tool can run out faster than you'd expect; if that happens, waiting a day or switching networks clears it. For always-on monitoring across regions, or for testing something genuinely internal-only, your hosting provider's own uptime tooling is the better fit than any browser-based checker, ours included.