About the HTTP Headers Viewer
The HTTP Headers Viewer fetches a web page from our server and shows the response headers it sends back: the status code, every redirect on the way, the caching and compression settings, the server and CDN, cookies, and the security headers that protect visitors. Enter an address, press Check headers, and read the results in a few seconds.
Headers are invisible in a normal browser window, yet they decide a lot: whether a page is cached, whether a redirect is permanent, whether the browser must use HTTPS, which scripts may run and whether other sites can frame the page. Developers, SEO specialists and site owners use this view to debug redirects, check a new server setup, or confirm that a CDN is in front of a site.
The request is made from the server, not from your browser, so the result shows what the outside world gets. For safety, only public http:// and https:// addresses on the standard ports can be checked; private networks and local addresses are refused.
How to use it
- Enter an addressType a full URL or just a domain like example.com; https:// is added for you.
- Choose the requestGET fetches the page like a browser; HEAD asks for the headers only. Pick a browser identity if the site serves different answers to phones or to Googlebot.
- Decide on redirectsLeave Follow redirects on to see every hop to the final page, or turn it off to inspect only the first answer.
- Read the summaryThe redirect chain shows each status code, protocol, time and server IP. The two panels list security checks and the caching and server details.
- Dig into the detailsFilter the full header table, copy all headers as text, or download everything as JSON.
Key features
Full redirect chain
Every hop with its status code (301, 302, 307, 308), the HTTP version, response time and the IP address that answered, up to five redirects.
Security header checks
Strict-Transport-Security, Content-Security-Policy, X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and cookie flags.
Caching at a glance
Cache-Control, Age, ETag and Last-Modified, plus the compression in use, such as gzip or br (Brotli).
CDN detection
Recognizes Cloudflare, Amazon CloudFront, Fastly, Vercel, Netlify, Akamai and Google from their headers.
Browser identities
Send the request as the tool's own checker, Chrome on Windows, Safari on iPhone or Googlebot.
Safe by design
Private, loopback and reserved addresses are blocked, every redirect is checked again, only ports 80 and 443 are allowed, and the page body is never downloaded.
Examples
A redirect to HTTPS
Checking http://github.com with Follow redirects on shows two hops:
| Hop | Status | Address |
|---|---|---|
| 1 | 301 Moved Permanently (HTTP/1.1) | http://github.com/ |
| 2 | 200 (HTTP/2) | https://github.com/ |
The first answer has just two headers, Content-Length: 0 and Location: https://github.com/. With Follow redirects off, the result stops there, with the status "301 Moved Permanently". HTTP/2 answers have no reason phrase, which is why the second hop shows only 200.
Reading the security checks
When this was written (October 2026), the GitHub home page passed most checks: HSTS for 365 days, a Content-Security-Policy, protection against framing, nosniff and a Referrer-Policy. Two warnings remained: no Permissions-Policy, and a cookie named _octo without the HttpOnly flag. The example.com page, served through Cloudflare, sent none of the security headers and got six warnings.
Warnings are not always mistakes. A simple page with no scripts and no logins gains little from a strict policy, and some cookies must be readable by JavaScript. Use the checks as a list of questions, not as a score.
Caching and compression
| Header | What it tells you |
|---|---|
| Cache-Control: max-age=0, private, must-revalidate | Browsers must check with the server every time; shared caches may not store it. |
| Age: 5 | A CDN served a copy that was 5 seconds old. |
| Content-Encoding: br | The page was compressed with Brotli. |
| ETag | A version tag the browser can send back to ask "has this changed?" |
Tips
- Check both http:// and https://, with and without www. All four should end at the same final address, ideally in a single 301 redirect.
- Use HEAD for a quick look, but compare with GET if something looks odd. Some servers answer HEAD requests differently.
- Switch the browser identity to Googlebot to see whether a site sends search engines somewhere different from visitors.
- After changing headers on your server or CDN, check again and look at the Age header to make sure you are not seeing an old cached copy.
- To see where a site's server is located and which network it belongs to, look up the IP from the redirect chain in the IP Address Lookup.
Common mistakes and limits
- Using 302 for a permanent moveA 302 or 307 says the move is temporary. For a page that has moved for good, use 301 or 308 so browsers and search engines update their links.
- Long redirect chainsEach hop adds a round trip. http → https → www → final page is three hops; one direct 301 to the final URL is faster.
- Setting HSTS too earlyStrict-Transport-Security with a long max-age makes browsers refuse plain HTTP for that time. Make sure HTTPS works everywhere, including subdomains if you use includeSubDomains, before you raise it.
- Expecting to check internal sitesIntranet pages, routers and localhost are blocked on purpose: the request comes from a public server and must not reach private networks.
- Reading Server versions as harmlessHeaders like "Server: nginx/1.18.0" or X-Powered-By with a version tell attackers which software to target. Hide version numbers where your server allows it.
