About the HTTP Header Inspector
This HTTP header inspector fetches a URL server-side and shows the full response: the status code, every response header, the chain of redirects it followed hop by hop, and how long the request took overall. It's the quick way to see exactly what a server returns, content type, caching headers, security headers, cookies, the server or CDN software, and any redirects, without opening browser developer tools or reaching for curl.
Use it to debug why http:// isn't redirecting to https:// the way you expect, confirm HSTS and other security headers actually made it into production, work out why a page keeps serving a stale cached version, or trace a chain of redirects that lands somewhere you didn't intend. It's a like-for-like replacement for curl -I, plus a fully resolved redirect trail you'd otherwise have to follow by hand.
The request is a single GET per URL, made server-side, with the response body read only enough to be discarded; only the status and headers are ever returned. It follows up to eight redirect hops automatically, and, unlike a naive fetch, re-validates the SSRF guard on every single hop rather than just the first request, since a redirect could otherwise be used to reach an internal address after the fact. Private, loopback and link-local targets are refused at every step, and only http and https URLs are accepted.
It's easy to confuse with two neighbouring tools here: the "is it up" checker gives a fast up/down verdict with timing for the same kind of request, and the email header analyzer parses an entirely different set of headers, the Received and Authentication-Results lines from an email message rather than an HTTP response. Reach for this one specifically when you need the actual header values.
How to use it
- Enter a full URL, including http:// or https://, since the scheme isn't assumed here.
- Submit to fetch the URL server-side with a single GET request.
- Follow the automatic redirect trace as each hop is re-validated against the SSRF guard.
- Read the final status code, status text and total request timing.
- Scan every response header for caching, security and server details.
- Compare the final URL against the one you entered to confirm exactly where you land.
Examples
- Confirm http://example.com redirects to https:// with a 301, not a 302, so search engines treat the move as permanent.
- Inspect cache-control, etag and age to work out why a page keeps serving a stale cached version.
- Check that strict-transport-security, content-security-policy and x-frame-options are all present after a security hardening pass.
- Follow a shortened or tracked link's full redirect chain to see every intermediate hop before it reaches the final URL.
- Read the server or via header to confirm which CDN or reverse proxy actually answered the request.
Headers worth checking
A response usually carries far more than a status code. These are the ones worth reading first:
- cache-control, etag, age, expires: caching behaviour, whether a CDN or browser is allowed to reuse the response
- strict-transport-security, content-security-policy, x-frame-options, x-content-type-options, referrer-policy: the core security headers a hardened site should send
- server, x-powered-by, via: what software or proxy actually answered, useful for fingerprinting a stack or confirming a CDN sits in front of origin
- set-cookie, access-control-allow-origin: session behaviour and CORS rules for cross-origin requests
- location: present on any 3xx response, the address the redirect actually points to
How the redirect chain is followed
Redirects are followed manually rather than by a library's automatic redirect handling, so each hop can be reported individually and re-checked against the SSRF guard before it's followed. Up to eight hops are allowed before the tool gives up with a "too many redirects" error. Each entry in the chain lists its own url, status code and location header, which makes a redirect loop or an unexpected intermediate domain easy to spot at a glance.
What this tool does and does not do
It's deliberately scoped to headers, not a browser replacement.
- does: a single GET request per URL, reads the status and every response header, follows and reports redirects, times the full chain end to end
- does not: download or render the response body, execute JavaScript, or check multiple URLs in one pass
SSRF guard and request limits
A request is refused up front, and again on every redirect hop, if it resolves to a private, loopback or link-local address. An 8-second timeout applies per hop, and only http and https schemes are accepted. This keeps the tool safe to run as a public service without it becoming a way to reach internal infrastructure through a chain of redirects.
Frequently asked questions
Is this the same as running curl -I?
Functionally close, yes: a single request that reads only the status and response headers. The difference is that this one also follows and reports the full redirect chain hop by hop, and runs from our server rather than your own machine.
Does it follow redirects?
Yes, up to eight hops. Each one is re-checked against the SSRF guard before it's followed, and the full chain, with each hop's URL, status and location header, is reported alongside the final response.
Can I inspect an internal or localhost URL?
No. Requests to private, loopback and link-local addresses are refused, on the first request and on every redirect hop, so the tool can't be used to probe internal infrastructure.
Does it download the page content?
No. Only the response headers are read; the body is discarded rather than downloaded or rendered, which keeps the check fast even against a large page.
How is this different from the 'is it up' checker?
The up checker gives a fast up/down verdict and timing for the same kind of request. This tool goes deeper: the exact status code, every response header, and the full redirect chain, closer to curl -I than a simple up/down light.
How is this different from the email header analyzer?
This tool inspects HTTP response headers from a web server: status, redirects, caching, security headers. The email header analyzer parses a completely different set, the Received and Authentication-Results lines from an email message. The two never overlap.
Can I check the redirect chain behind a shortened link?
Yes. Paste the shortened URL and the tool follows every redirect it produces, reporting each intermediate hop and the final destination URL, which is exactly what older "web sniffer" style tools were built for.
Why do I need to include https:// here but not in the 'is it up' tool?
This tool treats the scheme as significant, since http:// versus https:// can itself be the thing you're debugging, for example whether the redirect from one to the other actually happens. The up checker assumes https:// for convenience since that's rarely what's in question there.
What does a header checker actually check, in plain terms?
It sends a real request to the URL you give it and shows you everything the server said back other than the page content itself: the status code, every header, and where you end up after any redirects.