HTTP Header Checker — response headers and security policy
Fetch any site's response headers, check the six security headers that matter, and see how fast the server replied.
Free and instant — results appear in seconds. No sign-up, no limits, and nothing you type is stored.
Every HTTP response carries headers the browser reads before rendering anything: the status code, caching instructions, what software answered, and a set of security directives that constrain what the page is allowed to do.
Those security headers are worth attention because they are cheap to add and they close real attack classes. A missing X-Frame-Options allows your page to be framed inside someone else's site for clickjacking. A missing Strict-Transport-Security leaves the first request of every visit vulnerable to downgrade.
This tool sends a request, follows redirects, and reports what came back — including the six headers most often absent and what each one prevents.
Reading a typical result
A well-configured site returns something like:
HTTP/1.1 200 OK · 93.184.216.34 · 214 ms · server: nginxstrict-transport-security SET max-age=31536000; includeSubDomains
content-security-policy MISSING Restricts what resources may load
x-content-type-options SET nosniff
x-frame-options SET SAMEORIGIN
referrer-policy SET strict-origin-when-cross-origin
permissions-policy MISSING Gates camera, mic and geolocation
```
Four of six present, which is better than most sites.
HSTS with a one-year max-age tells the browser to refuse plain HTTP for this domain for the next year. The includeSubDomains flag extends that to every subdomain — powerful, and worth pausing over, because any subdomain without working HTTPS becomes unreachable for the duration. There is no quick undo; browsers honour the cached policy until it expires.
CSP missing is the common gap, and it is the one with real teeth against cross-site scripting. It is also the hardest to deploy, because a strict policy will block your own inline scripts and third-party embeds until you enumerate them. The practical route is Content-Security-Policy-Report-Only first, collect violations for a fortnight, then enforce.
nosniff stops the browser second-guessing a declared content type — which is what turns an uploaded file served as text/plain into executed JavaScript.
SAMEORIGIN blocks framing from other origins. If your site must be embeddable by a partner, use CSP's frame-ancestors instead, which allows a specific list.
214 ms is a reasonable server response time. Past roughly a second, the server is the bottleneck rather than the network, and no amount of front-end optimisation will hide it.
The six headers and what they cost
Strict-Transport-Security — forces HTTPS for a stated period. Enable only once HTTPS works everywhere, and add includeSubDomains only once every subdomain has a valid certificate.
Content-Security-Policy — controls which sources may supply scripts, styles, images and frames. The strongest protection against XSS and the most work to deploy.
X-Content-Type-Options: nosniff — prevents MIME sniffing. One line, no downside, add it.
X-Frame-Options — blocks framing. SAMEORIGIN suits most sites. Superseded by CSP frame-ancestors but still honoured.
Referrer-Policy — limits how much URL information leaks to other sites. strict-origin-when-cross-origin is a sensible default.
Permissions-Policy — disables browser features the site does not use, so injected code cannot reach for the camera or geolocation.
Of these, nosniff, X-Frame-Options and Referrer-Policy can be added in minutes with essentially no risk of breaking anything. HSTS and CSP need testing.
Headers that give away more than intended
A Server header reading Apache/2.4.29 (Ubuntu) or an X-Powered-By naming a specific PHP version tells an attacker precisely which published vulnerabilities to try first. Neither header serves any purpose for visitors.
Suppressing them is not security by itself — an unpatched server is unpatched whether or not it announces the version. But it removes free reconnaissance, and it costs nothing.
Reading redirect chains
This tool follows redirects, which is the right behaviour for checking the final destination but hides the path taken. Two things worth verifying separately:
Chain length. http://example.com → https://example.com → https://www.example.com is two hops where one would do. Each adds a round trip, and search engines dilute signals across long chains. Configure the server to reach the canonical form in a single 301.
Status codes. A 301 is permanent and passes ranking signals; a 302 is temporary and is treated as such. Using 302 for a permanent move is a persistent and quietly costly SEO mistake.
Response time in context
The figure reported here is time to first byte from this tool's location — server processing plus network latency, not full page load. It is useful as a rough signal: under 300 ms is healthy, 300 ms to 1 second is acceptable, and above a second points at the application or database rather than the front end.
Frequently asked questions
Which security headers should I add first?
Start with X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN and Referrer-Policy. All three are effectively risk-free to enable and take minutes. HSTS and Content-Security-Policy come next, but both need testing because a mistake in either can make parts of your site unreachable.
Is HSTS risky to enable?
It requires care. Once a browser caches the policy it will refuse plain HTTP for your domain until the max-age expires, and there is no way to retract it early. Adding includeSubDomains extends that to every subdomain, so any subdomain lacking a valid certificate becomes unreachable. Start with a short max-age and raise it once you are confident.
Why does my CSP break the site?
A strict Content-Security-Policy blocks anything not explicitly permitted, which usually includes your own inline scripts, inline styles and third-party embeds. Deploy it as Content-Security-Policy-Report-Only first, collect violation reports for a couple of weeks, allow what is legitimate, then switch to enforcing.
Should I hide the Server header?
It is worth doing. Version banners tell an attacker exactly which published vulnerabilities to try first, and they provide nothing to visitors. It is not a substitute for patching, but removing free reconnaissance costs nothing.
What is a good server response time?
Under 300 milliseconds is healthy, 300 milliseconds to one second is acceptable, and beyond a second the bottleneck is usually the application or database rather than the network. Note that the figure here measures time to first byte from one location, not full page load.
Why does the tool show a different status than my browser?
This tool follows redirects and reports the final response, so intermediate hops are not shown. It also sends no cookies and no browser-specific headers, so sites that vary their response by session or user agent may answer differently.
Reviews
No reviews yet. If this tool solved something for you, yours would be the first — and it helps other people decide whether it is worth their time.