HTTP header check: status, redirects and the headers worth reading
An HTTP header check shows the status code, the redirect chain and which security headers are missing. How to check HTTP headers without guessing from a browser plugin.
An HTTP header check is the raw conversation between client and server, before any rendering. People search for it as “http header check”, “check http headers”, “server header checker” and “http headers online”. The thing they want is the same: the status line, every response header, and the path a redirect took.
What a server header checker should show
- The final status code and the URL it belongs to, after redirects. The first hop is often a 301 that tells you nothing about the page.
- Each redirect hop: the URL, the status, and the Location it pointed at. That is the only way to see a loop or an accidental drop back to http://.
- The response headers as the server sent them. Browser devtools show the same bytes, mixed with headers your extensions added.
- Whether the TLS certificate was trusted. A header list from an https URL that never completed the handshake is not a header list.
The header checker on this site does that from Zurich, for a public http:// or https:// URL. It reads no response body. A browser plugin that injects scripts will not agree with it on every header, and that disagreement is the point of checking from outside the browser.
Check HTTP headers that change security, not just debugging
Most headers are informational. A short list is worth a deliberate yes or no, because their absence changes what a browser will do. Missing is not automatically a defect. It is a decision you should know you made.
| Header | If it is absent |
|---|---|
| Strict-Transport-Security | A browser may try http:// first on a later visit. Fine only if the site is not https-only. |
| Content-Security-Policy | Nothing restricts where scripts and styles may load from. |
| X-Content-Type-Options | Browsers may guess a response’s type instead of trusting the declared one. |
| X-Frame-Options | Another site can frame the page, unless a CSP frame policy already covers it. |
| Referrer-Policy | Full URLs, query string included, may be sent to other sites when a visitor follows a link. |
Server header checker versus what your browser shows
Devtools are the right tool for a header your own session added: a cookie, an Authorization value, a request body. They are the wrong tool for “what does an anonymous client get?”. Logged-in responses, cached 304s and extension-injected content-security policies all lie about the public site. An online check uses no cookies and no extensions.
Server and X-Powered-By are worth reading for a different reason. They name software. That is useful when you later want to know whether a published vulnerability applies to the version you run, and it is also information you may not want to advertise. The header check shows them; it does not turn them off.
curl -fsS https://api.hypermonitors.com/v1/tools/http \
-H 'content-type: application/json' \
-d '{"url":"https://example.com"}'The JSON includes finalUrl, status, headers, redirects and a certificate summary when the URL was https. Same limits as the status checker: public hosts, headers only, rate-limited. An HTTP monitor does not diff those headers. It follows redirects by default and treats 200–399 as up, unless you set the status codes you consider healthy. A security header can disappear and the monitor will still be green. Re-run the checker when the server config changes.