What does an HTTP header checker show?
An HTTP response header is a line the server sends before the page body — what type the response is, how long a browser may cache it, whether it is compressed, whether it may be framed, which scripts are allowed to run. This checker fetches one URL and shows every header that came back, then grades the ones that are supposed to be a defence: HTTPS itself, Strict-Transport-Security, Content-Security-Policy, frame protection, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, whether the server advertises its own version, and the Secure and HttpOnly flags on any cookie.
The fetch is made by this site's server, and that is not a shortcut — it is the whole reason the tool can exist. A browser hides another origin's response headers from JavaScript on purpose: only a fixed list of headers is exposed to a cross-origin script unless the site opts in with `Access-Control-Expose-Headers`, which almost none do. So a header checker that ran entirely in your browser could only ever report on your own site, and would silently see nothing from anyone else's.
What you get is a shape, not a verdict. A marketing site with no Content-Security-Policy can be entirely fine, and a deliberately strict site can grade worse than a careless one that happens to set one long header. The rows worth acting on are the ones a browser enforces: HSTS on your HTTPS site, frame protection so your pages cannot be clickjacked, and Secure and HttpOnly on cookies that carry a session. The grade is there to make the list scannable, not to be a score of your security.
How to check response headers for a URL
- Enter the full address, including https:// — the scheme matters, because HSTS and the HTTPS row are graded against the response you actually got.
- Press Check headers. The address is fetched once from this site. HEAD is asked for first, since only headers are wanted; a server that refuses HEAD is asked again with GET and the body is thrown away as it arrives.
- Read the security list top to bottom. Each row says what the header is for and what its absence allows, in the terms a browser uses it rather than the terms a spec does.
- Follow the grade: A from 90, B from 80, C from 70, D from 60. Fifteen points come off for a failed check and seven for a warning, so two failed and two warned puts a site at 56.
- Use Copy headers when you need the raw block — for a support ticket, a server config review, or pasting into a diff after a change.
- Fix one thing and re-run: add the header at the origin rather than at the CDN if you want it to survive a cache purge, and check that the change applies to the final response and not just the redirect.
HTTP header checks, limits and rules
| Item | Limit |
|---|---|
| Checks graded | HTTPS, HSTS, Content-Security-Policy, frame protection, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, version disclosure, cookie flags |
| Scoring | 100 minus 15 per failed check and 7 per warning, floored at 0 |
| Grades | A at 90+, B at 80+, C at 70+, D at 60+, F below |
| HSTS threshold | max-age under 180 days is a warning, and a missing max-age fails |
| Request | HEAD, falling back to GET with the body discarded; no cookies or credentials of yours are sent |
| Redirects | Followed, up to 5 hops, because the page a visitor lands on is the one worth grading |
| Per request | 12 seconds, 6 of them for the connection |
| Rate limit | 40 checks per minute per visitor |
| Not included | TLS certificate validity, CSP effectiveness against real payloads, HTTP/3 support, whether a WAF adds headers later, and anything set by client-side JavaScript |
| Not verified | Header values differ by CDN edge and by region, so a result from this server is one vantage point, not every one |
When to use it
- Confirming that HSTS, frame protection and nosniff are actually being sent after you added them to nginx, Apache, IIS or .htaccess.
- Checking whether a CDN is stripping or rewriting security headers the origin sets, and which layer the header is coming from.
- Auditing cookie flags on a login response — a session cookie without Secure travels on http:// and is readable by any script on the page.
- Seeing what a site you are about to rely on sends: caching, compression and MIME type, before you build against it.
- Taking a before-and-after snapshot of the raw header block when you harden a server, so the change is evidence rather than memory.
Is it private?
This check runs on the server, and it has to: a browser will not show JavaScript another origin's response headers, so a page cannot do this for you. When you press the button, your browser sends the address to this site's own endpoint, which fetches it once with a crawler user agent and returns what came back. The site you check sees a request from this server and never learns who asked. No cookies, no credentials and nothing about your browser are forwarded, and your IP is only counted against a per-hour meter that stops the endpoint being used as a free fetcher. The address and the headers are not stored; the result is shown to you and dropped.
Frequently asked questions
Because of the same-origin policy. A cross-origin response exposes only a short list of headers to JavaScript — `Content-Type`, `Cache-Control` and a few others — and everything about security is deliberately left out unless the site sends `Access-Control-Expose-Headers`, which is rare. A browser-only version would report your own headers and nothing but blanks for anyone else's. So the request is made by this site's server instead, which is stated on the page rather than hidden.
The most common causes, in order: a CDN or reverse proxy caching the old response, so purge it or check the origin directly; the header added to the wrong virtual host, or to a block that handles http:// but not https://; the redirect answered before the application ever saw the request, so the header is on the hop you are not grading; and a server that ignores HEAD, where the fallback GET should still show it. Check the raw block at the bottom — if the header is not in that list, the browser is not getting it either.
No. The grade exists to make a list scannable, and it weighs a missing Permissions-Policy the same as a missing Content-Security-Policy, which is not how risk works. Read the rows instead. The three that change behaviour rather than hygiene are HSTS on an HTTPS site, frame protection against clickjacking, and Secure and HttpOnly on a session cookie. Everything else is defence in depth: worth having, rarely the thing that gets you breached.
Strict-Transport-Security tells a browser to refuse plain HTTP to your hostname for the lifetime in max-age, and to remember that decision locally before making any request. So it closes the window where a first visit over http:// can be intercepted before your redirect to HTTPS arrives — the gap that a redirect alone never closes. A short max-age means the memory expires sooner; six months is the usual floor, and adding preload asks browsers to ship that rule for your domain in their own release.
Because a response is generated per request, and often per edge. A CDN may serve one header set from the node nearest you and another from the origin, add its own headers, or vary `Vary`-listed headers by device and region. Rate limiting and bot protection can also change the answer for a request that looks automated. This checker reports one vantage point — this server — which is why the address of the socket that answered is shown next to the result.
Every Set-Cookie header on the response. A cookie without Secure may be sent over http://, where anyone on the network path can read it. A cookie without HttpOnly is readable by JavaScript, so a single injected script can exfiltrate it. Session cookies belong with both, plus SameSite to control cross-site sending. Cookies that only carry a preference are not a problem without them, which is why this shows as a warning with the names rather than a failure.
Related tools
Written and maintained by Md. Nur Hossain Repon.