HTTP Header Checker

HTTP Header Checker shows, in real time, the exact response status code and headers a server returns for a given URL. Without opening browser dev tools, you can review security headers (HSTS, CSP, X-Frame-Options), caching policy (Cache-Control, ETag), the server software, and content type at a glance.

Requests go through a safe server-side proxy, so you see every header verbatim without CORS restrictions. When redirects occur, each hop is traced and the final destination URL and status code are shown together. Just enter a URL.

Key response headers at a glance

• Content-Type: the body's MIME type and character encoding (charset)
• Cache-Control / ETag / Last-Modified: caching and revalidation policy
• Strict-Transport-Security: whether HTTPS is enforced (HSTS)
• Content-Security-Policy: restrictions on script and resource origins
• X-Frame-Options: framing restrictions to prevent clickjacking
• Server: server software (be cautious about exposing it)

Reading status codes and redirects

2xx means success, 3xx a redirect, 4xx a client error, and 5xx a server error. This tool follows redirects such as 301 and 302 and records each hop, so you can confirm that http to https enforcement or www normalization works as intended. If the final URL differs from your input, a redirect occurred.

How to use it

It is great for quickly verifying after a deploy that security headers are not missing, that your CDN and cache policy is applied, and that there are no broken redirect loops. Only headers are fetched, not the body, so it stays light and fast. To grade just the security headers, use the security headers checker; to trace a redirect chain hop by hop, use the HTTP status & redirect checker.

Header value cheat sheet

The values you meet most often in practice, and what they actually mean. Compare against the recommended setup to spot missing configuration fast.

Reading a redirect chain: worked example

A typical flow you see when you enter http://example.com:

• Hop 1 http://example.com → 301 Moved Permanently, Location: https://example.com/ (HTTP to HTTPS enforcement)
• Hop 2 https://example.com/ → 301, Location: https://www.example.com/ (www normalization)
• Hop 3 https://www.example.com/ → 200 OK (final destination)

Here the Strict-Transport-Security header on the hop 1 response is effectively useless: browsers ignore HSTS sent over plaintext HTTP, so HSTS must be present on the HTTPS responses in hops 2 and 3. Also, if hop 1 to 2 is a 301 (permanent) and you point it at the wrong host by mistake, browsers and search engines cache it and it is hard to undo — start with 302 (temporary) when you are not certain.

Common pitfall

• Reading no-cache as “don’t cache” — it actually caches but revalidates before each use. To truly prevent caching, use no-store.
• Setting HSTS on the HTTP response and assuming you are covered — browsers always ignore HSTS on plaintext responses; it must be on the HTTPS response.
• Judging by the final URL’s headers only — a missing security header is usually on an intermediate redirect hop. Inspect every hop.