HTTP Header Inspector
Inspect a URL's response status, headers, and redirect chain.
What is the HTTP Headers tool?
The HTTP Headers tool takes a URL, sends it a GET request, and shows you the full set of response headers the server returns, the final status code, and the redirect chain the request followed. You can see exactly how headers like Content-Type, Cache-Control, Set-Cookie, Strict-Transport-Security, and Content-Security-Policy come down the wire — without opening your browser's dev tools.
The request is made on the server on your behalf. A browser making a direct cross-origin request can't read most response headers due to CORS, and can't observe intermediate redirect hops from JavaScript in the first place. The server follows redirects manually (redirect: manual) up to 10 hops, recording each hop's status code and Location before returning them.
This is handy for verifying that caching policy (Cache-Control, ETag) is applied as intended, that security headers like HSTS, CSP, and X-Frame-Options are set, how an http→https or www redirect happens (301 vs 302, and how many steps), and which headers a CDN adds (e.g. cf-cache-status). The server blocks requests to internal network addresses (SSRF protection) and re-validates this at every redirect hop.
How to use
- Enter the URL to check (e.g. https://example.com). If you omit the scheme, it's assumed to be https.
- Click 'Check Headers' and the server sends a GET request to that URL, following any redirects to the end before returning the result.
- If there were redirects, each hop's status code and URL appear as a chain at the top; below that you'll see the final status code and the complete header list. Copy any header value with its copy button.
Frequently asked questions
- How is this different from the browser's Network tab?
- Dev tools show requests the browser actually renders, but CORS restrictions and automatic redirect following make it hard to see raw cross-origin response headers or intermediate redirect hops as-is. This tool makes the request server-side, so it exposes the full response headers unaffected by CORS along with every redirect hop.
- I get a 'too many redirects' error.
- The server follows at most 10 redirect hops. Anything beyond that usually means a redirect loop or a misconfigured chain. Check the listed hops for a repeating URL or a segment bouncing between http and https.
- I can't look up localhost or an internal IP.
- To prevent SSRF (server-side request forgery), requests to internal or private network addresses are blocked, and attempts to bypass this via redirects are re-validated at every hop. Only URLs reachable from the public internet can be checked.
- Some headers look different from a real browser request.
- The server requests with a fixed User-Agent (DevTools/1.0) and sends no cookies or credentials. Servers that vary their response by User-Agent or by authentication/session may therefore return different headers than you'd see browsing directly.