HTTP Headers Checker
See the HTTP response headers and redirect chain of any URL, with a security headers audit.
Loading HTTP Headers Checker… If nothing happens, please enable JavaScript.
Every web response starts with a block of HTTP headers that the visitor never sees: the status code, where a redirect points, how long the page may be cached, which content type it is, and a set of security instructions for the browser. Most SEO, performance and security problems leave their first trace there, a redirect loop, a 302 that should be a 301, a missing HSTS header, a CDN that refuses to cache. This tool fetches a URL from our server and shows those headers exactly as they arrive.
Examples
http://github.com
301 → https://github.com/ → 200
One redirect from HTTP to HTTPS, then the final page with HSTS, CSP and X-Frame-Options set.
Cache-Control: max-age=0, private, must-revalidate
Stored, but revalidated with the server on every use (browser only, not CDNs).
The caching summary translates directives into plain language.
Frequently asked questions
What is the difference between a 301 and a 302 redirect?
How many redirects are too many?
Which security headers matter most?
Why do I see different headers than in my browser's developer tools?
Why does the tool say GET instead of HEAD?
Can I check a page on localhost or my internal network?
Does the tool check the TLS certificate?
Are the URLs I check stored?
About HTTP Headers Checker
Paste a URL and the checker requests it the way a browser would, without following redirects automatically. Each hop is shown in order with its status code, response time and full header list, so you can see the whole path from http://example.com to the final https://www.example.com/ and spot extra hops that slow down the first visit. Click any hop to see its headers, filter them by name or value, and copy them as raw text.
The final response gets a security header audit. The tool checks Strict-Transport-Security (and its max-age), Content-Security-Policy (and whether it still allows unsafe-inline scripts), X-Frame-Options or CSP frame-ancestors against clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy, and points out headers that reveal server software versions. Each item explains in plain language what the header does and what is missing. A separate section translates Cache-Control, Expires, ETag, Age and Vary into a one-line answer about how the page is cached.
Requests come from our server, so you see the public response, not what your browser or a local proxy sends. A HEAD request is tried first and a GET is used when the server rejects HEAD, stopping as soon as the headers arrive so no page body is downloaded. Only http and https on ports 80, 443, 8080 and 8443 are allowed, every redirect target is checked again, and private or internal addresses are blocked.
Headers that outlived their purpose
HTTP headers accumulate history. The Referer header is misspelled because Phillip Hallam-Baker wrote it with one 'r' in the 1990s draft, and by the time anyone noticed, servers everywhere depended on it. The newer Referrer-Policy header is spelled correctly, so the web now carries both spellings side by side.
X-XSS-Protection is a header that was later turned off on purpose. Internet Explorer 8 introduced an XSS filter in 2008 and Chrome followed, but researchers found that the filter itself could be abused to leak data or disable legitimate scripts. Chrome removed its XSS Auditor in 2019, and the recommended value today is 0, or no header at all, with Content-Security-Policy doing the real work.
The X- prefix itself was officially deprecated by RFC 6648 in 2012. The idea had been that experimental headers would carry X- and drop it once standardised, but popular headers like X-Forwarded-For and X-Frame-Options never lost the prefix, so renaming them would only have broken things. New headers are now registered without it from the start.