HTTP Headers Checker
Inspect HTTP response headers and security posture of any URL.
🌐 sitekits fetches the URL server-side (private/internal addresses are blocked). Response body is not retrieved.
Overview
Response headers are where most of a site’s behaviour is actually configured — caching, compression, security policy, CORS, redirects — and they are the part you cannot see in the browser without opening DevTools on the right request.
This tool requests a URL server-side and returns the response headers, plus the full redirect chain that got there. Because the browser’s own security model hides cross-origin response headers from JavaScript, this is one of the few tools here that cannot run entirely in your page.
How to use
- Enter a URL. The scheme is optional —
example.comis treated ashttps://example.com. - Read the redirect chain first. Each hop shows its URL and status code.
- Read the final response headers.
Redirect chains are usually the answer
When something is slow or a canonical URL is wrong, the chain is where you see it. Every hop is a full round trip, and the common patterns are all avoidable:
http://example.com→https://example.com→https://www.example.comis two redirects where one would do. Redirect straight to the final host and scheme in a single hop.- A
301that lands on another301after a site migration means two generations of rules are both still active. - A redirect to a URL that redirects back is a loop; the tool stops after five hops rather than following it.
- A
302where you meant301tells crawlers the move is temporary, so the old URL keeps its ranking and the new one does not accumulate any.
The distinction between 301/302 and 307/308 is the request method.
Historically clients turned a POST into a GET when following 301 and
302; 307 and 308 preserve the method. If a form submission behaves
strangely behind a redirect, that is the first thing to check.
Headers worth reading closely
| Header | What to look for |
|---|---|
cache-control | no-store on a static asset wastes bandwidth; a long max-age on HTML makes deploys invisible |
etag / last-modified | Absence means every revalidation transfers the whole body again |
content-encoding | Missing gzip or br on text responses is the cheapest performance win available |
vary | Vary: User-Agent fragments every CDN cache into hundreds of copies |
strict-transport-security | A short max-age, or a missing includeSubDomains, leaves the first request downgradeable |
content-security-policy | See the CSP builder for what the directives mean |
x-content-type-options | Without nosniff, a mistyped content-type can be reinterpreted as script |
access-control-allow-origin | The reason your fetch fails is almost always here, or absent |
set-cookie | Check Secure, HttpOnly and SameSite on anything that carries a session |
server and x-powered-by are worth noticing for the opposite reason: they
disclose software versions and nothing else. Removing them is not a security
control, but there is no argument for keeping them.
What the tool deliberately does not do
The handler validates the URL against a blocklist of private, loopback,
link-local and reserved address ranges before connecting, and repeats that
check on every redirect hop. Without the per-hop check, a public hostname
could redirect to 127.0.0.1 or a cloud metadata address and the request
would follow it — which is how a header-checking service becomes a way to
probe someone else’s internal network from the outside.
It also never forwards the response body. The connection is read for headers and dropped. A service that returns arbitrary bodies is an open proxy whether or not that was the intent.
Credentials embedded in a URL (https://user:pass@host/) are stripped before
the request is made, so they are neither sent to the target nor echoed back in
the redirect chain.
Examples
- A CORS error you cannot reproduce. Compare
access-control-allow-originon the real endpoint against what your code expects. An absent header and a wrong header produce the same browser message. - A deploy that will not show up. Look at
cache-controlandageon the HTML. A CDN serving a cached document explains it more often than the build. - Auditing a security header rollout. Check
strict-transport-security,content-security-policyandx-content-type-optionson the live host rather than in your config, because a CDN or WAF may add, strip or override any of them. - Verifying a canonical redirect. Confirm the chain ends in exactly one hop at the host and scheme you intend.
Notes
Requests use a fixed User-Agent identifying this tool, and time out after
five seconds. A site that blocks unknown agents will answer with a 403, which
is a real answer about that site’s configuration rather than a failure here.
Header names are shown as the server sent them. HTTP/2 requires lowercase names
on the wire, so a response over HTTP/2 will show content-type where an
HTTP/1.1 response might show Content-Type. The names are case-insensitive
either way.
If you need to send custom headers, a specific method, or a request body, use the REST API tester instead — it runs from your own browser and so can do things a shared service must not.