HTTP headers checker
See the status code and every response header a URL sends, through each redirect. Security, caching, cookie and server headers are grouped and explained, with a quick check of what is missing.
- Follows up to 10 redirects
- Checks 6 key security headers
- No signup needed
Final status
Enter a URL to start
- RequestWaiting for inputMethod and URL
- Redirects—Hops followed
- Response—Final status line
- Security—Key headers set
Response headers
Enter a URL above to see its status code and response headers, grouped into security, caching, content, cookies and server, with each redirect hop shown.
Fair-use limit: 30 checks per hour and 200 per day for each visitor IP address.
What HTTP headers tell you
Before any page content arrives, the server sends a status line and a list of headers. They decide how browsers, caches and search engines treat the response.
The status code comes first
200 means the page was served, 301 and 302 send the visitor elsewhere through the Location header, 404 means not found and 5xx means the server failed.
Security headers instruct the browser
Headers such as Strict-Transport-Security and Content-Security-Policy switch on protections in the visitor's browser. They cost nothing to send and are invisible on the page.
Caching headers decide who keeps a copy
Cache-Control, ETag and Last-Modified tell browsers and CDNs how long they may reuse a response. CDN headers such as cf-cache-status show whether the copy came from the cache.
Every redirect hop has its own headers
A 301 from http to https is a separate response. Security headers set only on the final page do not protect the hops before it.
The six security headers this tool checks
What each one does, a common safe value, and what happens without it.
| Header | What it does | Common value | Without it |
|---|---|---|---|
Strict-Transport-Security |
Tells browsers to use HTTPS only for this site | max-age=31536000; includeSubDomains |
Visitors can be downgraded to http on their first request |
Content-Security-Policy |
Lists where scripts, styles and frames may load from | default-src 'self'; frame-ancestors 'self' |
Injected scripts run with no extra barrier |
X-Content-Type-Options |
Stops browsers guessing the file type | nosniff |
An upload could be run as a script |
X-Frame-Options |
Controls who may show the page in a frame | SAMEORIGIN |
Other sites can frame the page for clickjacking |
Referrer-Policy |
Limits the address sent to other sites on clicks | strict-origin-when-cross-origin |
Browsers use their default, which is usually fine |
Permissions-Policy |
Turns off browser features the site does not use | camera=(), microphone=(), geolocation=() |
Embedded content may ask for those features |
How this tool works
What happens between pressing Check and seeing the headers.
You enter a URL
A full address such as https://example.com/page/, or just a domain. You can pick GET or HEAD and the user agent our server sends.
The address is checked
Our server resolves the host, refuses private or internal addresses and connects to the checked IP only, on port 80 or 443.
Redirects are followed
Each redirect is checked the same way, up to 10 hops, and every hop keeps its own status line and headers.
You get the report
Headers grouped by purpose with plain-English notes, a security and caching check, the raw text and the exact request we sent.
What this tool does, and what it doesn't
A plain list, so you know exactly what to expect.
This tool does
- Show the status and headers of every redirect hop
- Keep repeated headers such as Set-Cookie separate
- Check 6 security headers and cookie flags
- Explain caching, compression and CDN headers
- Let you choose GET or HEAD and the user agent
- Show the exact request our server sent
This tool does not
- Get past firewalls or bot challenges
- Send cookies or log in to a site
- Show the page content or run JavaScript
- Check private, internal or non-standard ports
- Test a Content-Security-Policy in depth
- Store the URLs or headers you check
Where your data goes
The URL you enter is requested by our server, with the method and user agent you choose and no cookies. The target site sees our server's IP address, not yours. The headers go straight to your browser and are not stored. A hashed, temporary copy of your IP address is used for rate limiting. Like any website, our server may keep normal access logs, as described in our privacy policy.
Step-by-step guide by Bhavin J. Sheth.
Why your results might look unexpected
The six surprises people run into most, and what each one means.
403 or a challenge page
A firewall or bot protection is blocking data centre traffic. Try the Chrome user agent. If it still fails, the site is choosing not to answer automated checks.
405 Method Not Allowed
The server refuses HEAD requests. Switch the method to GET, which is what browsers use.
Too many redirects
The chain loops or passes 10 hops, usually two HTTPS or www rules fighting. Fix the rules so each address redirects once to its final URL.
No Strict-Transport-Security
It only counts on HTTPS responses. Add it on the HTTPS site once every page works over HTTPS, starting with a short max-age.
Cache-Control: no-cache or private
The page cannot be cached by shared caches. Common for logged-in pages and some plugins. Check the CDN cache status header too.
Timeout or connection failed
The server did not answer within 6 seconds, the domain does not resolve, or the HTTPS certificate is invalid.
Questions about HTTP headers
Why do I get 403 or a challenge here when the site opens fine in my browser?
Many sites use a firewall or bot protection, such as Cloudflare or Akamai, that blocks or challenges requests from data centre addresses like our server. A header such as cf-mitigated: challenge shows this. Try the Chrome user agent, but some sites will still block automated checks, which is their choice.
Should I use GET or HEAD?
GET is what browsers send, so it shows the headers visitors really get. HEAD asks for the headers without the page and is lighter, but some servers answer HEAD differently or refuse it with 405 Method Not Allowed. Use GET unless you have a reason not to.
Which security headers should a website send?
The usual set is Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, a frame rule (X-Frame-Options or CSP frame-ancestors), Referrer-Policy and Permissions-Policy. Start with the simple ones. A Content-Security-Policy needs testing, because a strict policy can block your own scripts.
Does the tool follow redirects?
Yes, up to 10 hops, and each hop is shown with its own status and headers, so you can see whether http goes to https and www to non-www in one step or several. Untick Follow redirects to see only the first response.
Why is there no Content-Encoding: gzip or br?
Our request says it accepts gzip, deflate and br, like a browser does. If the response has no Content-Encoding, the server did not compress it. That is normal for redirects, empty responses and some HEAD answers, but an HTML page should normally be compressed.
Why do I see different headers in my browser?
Your browser may send cookies from a logged-in session, use a different CDN location, or get a cached copy. Caching plugins and CDNs often answer logged-in users and visitors differently. This tool sends no cookies, so it shows what a new visitor gets from our server's location.
Who sees the URLs I check, and are they stored?
Our server requests the URL, so the target site sees our server's IP address and the user agent you chose, not your IP. The URL and headers are not stored. A hashed, temporary copy of your IP address is used for rate limiting and expires within 24 hours. Like any website, our server may keep normal access logs, as described in our privacy policy.