HTTP Header Inspector
Queries a public record from our server — not your files.
See every header a URL responds with, and every redirect on the way, one hop at a time. A browser will not show you this for a site you do not control: it follows redirects before you see them and exposes only a handful of headers across origins. So our server makes the request instead, with redirects unfollowed, and reports each hop with its full header set. It fetches a public URL and reads only the headers — never the page content, and never anything from your device.
This tool is an exception on this site. Everything else here runs entirely in your browser, but a web page cannot query DNS, read a certificate or see another site’s response headers — so the name or URL you enter is sent to our server, which looks up the public record and sends the answer back. The answer is cached for up to a minute. No file of yours is read, uploaded or stored, and there is no account.
How to use HTTP Header Inspector
- 1
Enter a URL. Leave the scheme off and https:// is assumed; enter http:// deliberately to test the redirect.
- 2
Read the hop list — two or more redirects is a round trip you can usually remove.
- 3
Check the findings for missing security headers and cookies set without Secure or HttpOnly.
Share
Embed this tool on your site
Paste this where you want the tool to appear. It runs entirely in your visitor's browser — no uploads, no account, no tracking.
Please keep the attribution line — it's what keeps these tools free.
Need a different size, a dark theme, or a different tool? Build an embed lets you preview it first.
Frequently asked questions
Does this send my data anywhere?+
It sends the URL you type to our server, which makes an ordinary GET request to it from a Cloudflare data centre and reads the response headers. The body is discarded without being read or returned. Do not paste a URL containing a session token or a signed link — it will be requested, and it will appear in that site's access log. Credentials embedded in a URL are refused outright.
Why can I not do this in the browser console?+
The same-origin policy. A cross-origin fetch exposes only the CORS-safelisted response headers — six of them — unless the other site opts in with Access-Control-Expose-Headers, which almost nobody does. And fetch follows redirects itself, so the intermediate hops are gone before your code runs. The request has to come from a server.
Why does the redirect count matter?+
Every hop is a full round trip before anything renders, and on a phone connection that is real time. The usual cause is two rules that were never combined: http→https and www→apex, applied one after the other. One rule that jumps straight to the final URL removes a hop for every visitor.
It reports a different status than my browser shows.+
Most often because your browser is using a cached response, or is already on HSTS and never makes the http request at all. Sites also vary responses by user agent, by cookie, or by country — this request is made from a data centre with no cookies and a plainly identified user agent, which is closer to what a crawler sees than to what you see.
Are the missing headers it lists actually required?+
None is mandatory, and each is one line of configuration that closes a category of attack. The list is deliberately short — HSTS, CSP, nosniff, Referrer-Policy and framing protection — rather than a scored grade, because a long checklist encourages adding headers nobody understands.