HTTP Headers Checker - Status, Security & Cache

See the exact response a server sends: status code, full redirect chain, every header, plus a pass or fail verdict on the six security headers that matter and a read of the caching, compression and server disclosure settings.

The request comes from a ToolForte server.

The rest of ToolForte runs inside your browser, but a browser cannot read another site response headers for you. This request is therefore made server side and sends the user agent ToolForteBot/1.0. Site owners may block that string, and CDNs sometimes answer bots with a challenge page, so the headers you see can differ from the ones your own browser receives. No cookies, no authorization header and none of your own request headers are forwarded, so what you get is the anonymous first response for that address.

What a response header check tells you

Every page a server sends is wrapped in headers that the visitor never sees but the browser obeys. This checker requests an address, follows the redirects by hand and prints the status code, each hop in the chain and every header in the final response. On top of that raw view it grades the six headers that decide how hard the page is to attack, summarises the caching directives, and points out where the server names itself and its version in a way that helps nobody except a scanner.

It is built for the moment something behaves strangely and the markup is not to blame. A developer confirming that a new reverse proxy really adds the headers the config promises, an operations engineer working out why a page is cached far longer than intended, a security reviewer taking a first pass over a domain, or a site owner who received a scan report full of header names and wants to see the current state for themselves. The full table matters as much as the verdicts, because the odd custom header often explains the odd behaviour.

Headers travel with every HTTP response, and browsers act on them before a single pixel is painted. Strict-Transport-Security removes the plain HTTP first request entirely. Content-Security-Policy decides which scripts may run. X-Content-Type-Options stops content sniffing. X-Frame-Options, or the newer frame-ancestors directive inside CSP, decides whether another site can put your page inside a frame. Referrer-Policy controls how much of the current address leaks on outbound clicks. Permissions-Policy gates camera, microphone and geolocation.

A few numbers help when reading the output. HSTS wants a max-age of at least 15552000 seconds, which is 180 days, and preload lists insist on 31536000. A cache-control of max-age 31536000 with immutable is the standard for fingerprinted assets, while HTML usually wants no-cache so it revalidates. An age header above zero means a proxy served you a stored copy. Compression through gzip or brotli commonly removes two thirds of the transfer size of a text response.

Header work pairs naturally with the rest of the technical toolbox here. Look up what a specific code means with our HTTP Status Codes reference, confirm that redirects land where you think with the Canonical Checker, and when the response is fine but the markup is wrong, run the same address through the Meta Tag Checker. For the network layer underneath, DNS Lookup and IP Address Lookup answer the questions headers cannot.

How the HTTP Headers Checker Works

  1. 01Enter any public address. The scheme is optional, https is assumed when you leave it off.
  2. 02A ToolForte server makes the request as ToolForteBot with no cookies and no forwarded headers, so you see the anonymous first response.
  3. 03Redirects are followed one hop at a time, up to four, and each hop is recorded with its status code and destination.
  4. 04The final response is broken out into a security verdict, a caching summary, a server disclosure note and a full table of every header returned.

What to fix first in a header report

Work down from the headers that change what an attacker can do. Content-Security-Policy is the heaviest lift and the largest gain, because it decides which scripts may run at all: a policy that names your own origin and your handful of third parties turns an injected script tag into a blocked request. Strict-Transport-Security is the cheapest real win, one line that removes the plain HTTP first request forever, though it is also the one to think about before you ship, since a long max-age is hard to walk back if part of the site is not ready for HTTPS. X-Content-Type-Options with nosniff costs nothing and closes a whole class of upload attacks. Framing protection through X-Frame-Options or CSP frame-ancestors matters for anything with a logged in state. Referrer-Policy and Permissions-Policy are quick tidy ups rather than emergencies. After security, read the caching block. HTML normally wants no-cache so it revalidates on every visit, while fingerprinted assets want max-age of a year with immutable. An age header above zero means a proxy handed you a stored copy, which is often the real explanation for the change that supposedly did not deploy. Finally remove x-powered-by and trim any version number out of the server header. Neither helps a visitor, and both shorten the work for anyone scanning for known holes.

When to Use the HTTP Headers Checker

Reach for it whenever the symptom lives in the response rather than the page. A stale version keeps appearing after a deploy, and you want to know whether a CDN is serving a cached copy. A new reverse proxy or edge config went live and you want proof the headers it promises are actually being added. A security scan came back with a list of header names and you want to see the current state in plain language. A page loads slowly and you suspect it arrives uncompressed. It is also the fastest way to see a redirect chain end to end, which is the usual answer when a URL takes a suspiciously long time to settle.

Common Use Cases

  • Proving that a new reverse proxy, edge config or middleware really adds the security headers its configuration claims.
  • Working out whether a stale page is a caching problem by reading cache-control, etag and the age header on the live response.
  • Turning a scanner report full of header names into a concrete list of what is present and what is missing.
  • Looking up what an unfamiliar status code in a redirect chain actually means. → HTTP Status Codes
  • Checking whether a response arrives compressed before you go hunting for slow database queries.

Expert Tips

  • Roll out Strict-Transport-Security in stages. Start with a max-age of a few minutes, confirm nothing breaks on subdomains, then raise it. A long max-age is enforced by the browser and cannot be withdrawn quickly.
  • Ship a Content-Security-Policy in report-only mode first. You will find out which sources your site genuinely uses without breaking anything, and the fails in this tool will remind you that report-only alone blocks nothing.
  • If x-frame-options is missing but the CSP declares frame-ancestors, you are covered on every current browser. Adding the older header back is harmless but not urgent.
  • Check the same URL with and without a trailing slash. Redirect chains often hide there, and each extra hop is a full round trip before anything renders.

Frequently Asked Questions

Why do the headers here differ from the ones in my browser devtools?→
Because this request is anonymous and comes from a server. No cookies, no session, no authorization header and no browser fingerprint are sent, and the user agent is ToolForteBot/1.0. CDNs and bot protection frequently vary their response on exactly those signals, so you may be seeing a different cache entry, a challenge page, or simply the logged out version of the page.
Is a failing security header an actual vulnerability?→
Not by itself. These headers are defence in depth: they reduce the damage when something else goes wrong. A missing Content-Security-Policy does not create an injection hole, it removes the safety net if one appears. Treat a fail as a gap worth closing rather than an incident, and weigh CSP in particular against the work of enumerating every script source your site legitimately loads.
Why does the tool mention version numbers in the server header?→
Because publishing your exact release does nothing for visitors and quite a lot for anyone running a scanner. A server header of nginx is fine. One that names a specific patch version tells an attacker which published vulnerabilities to try first, before they have done any work at all. The same applies to x-powered-by, which is safe to remove entirely.
Can I check a page that needs a login?→
No. The request carries no cookies and no credentials, and there is no way to supply them. That is a deliberate limit: a tool that accepted session tokens would be asking people to paste their own credentials into a website. For authenticated pages, read the headers in your browser devtools on the Network tab instead.

Related tools

12 suggested

From the blog

Further reading