HTTP Header Checker
View the full request and response headers for any URL, including caching, compression and server details.
About the http header checker
HTTP headers carry metadata alongside a request or response that never appears in the page content itself but controls how browsers, caches and proxies behave. This tool requests a URL and shows the complete response, along with the request headers that were sent, so you can inspect exactly what a server returns without opening browser developer tools yourself. Response headers reveal the server software and version if disclosed, the caching policy through Cache-Control and ETag, whether the response is compressed with Content-Encoding, any cookies being set, and redirect targets. Together these explain a surprising amount about how a site is built and hosted, which is also why some operators deliberately suppress headers like Server to reduce information disclosure.
Caching headers are worth particular attention: a static asset with a long max-age and immutable is cached aggressively by browsers and CDNs and only re-fetched when its URL changes, typically via a content hash in the filename, while an HTML page usually wants a short or no-cache policy so visitors reliably see updates. Since some servers and CDNs vary their response based on the User-Agent header or other request headers, this tool lets you choose which User-Agent to send, so you can check whether, for example, a bot or a mobile client receives different headers than a typical desktop browser.
Before any of that, the check answers a blunter question: does the origin answer at all, over HTTPS, and does plain HTTP redirect to it. An origin that refuses the connection, times out, or fails to resolve produces no headers to grade, and we report that as the finding rather than as an empty result. Plain HTTP left open without a redirect is reported too, because it leaves a window in which a first request can be intercepted before HSTS has ever been seen; the fix is a 301 to the same host and path on HTTPS, with only the ACME challenge path left reachable over plain HTTP so certificate renewal keeps working.
Because headers can reveal more about a server's configuration than most operators intend, comparing what a fresh deployment returns against what was expected is a useful sanity check after any infrastructure change, catching an accidentally exposed debug header or a caching policy that reverted to a default. A quick comparison after a deployment takes only a minute and reliably catches an accidentally exposed debug header, a caching policy that silently reverted to a platform default, or a cookie that lost a flag it previously had.
Common questions
- What can I learn from response headers?
- Server software, caching policy, compression, cookies, redirect targets and any security headers the site sends, all without needing browser developer tools.
- Why do headers differ between browsers or tools?
- Servers and CDNs can vary responses based on the User-Agent header; this tool lets you pick which User-Agent to send so you can compare.
- What is a good Cache-Control value for static assets?
- public, max-age=31536000, immutable is standard for files whose names already include a content hash, since the URL itself changes whenever the content does.
- Why is my Server header missing?
- Some operators deliberately omit or generalize it to reduce information disclosure about the exact software and version running, which is a reasonable hardening step, not a bug. A Server header naming the software without a version is not reported; one naming the exact version is.
- Should I redirect HTTP to HTTPS, or just close port 80?
- Redirect. Closing port 80 means a visitor who types the address without a scheme gets a connection error rather than your site, and it breaks HTTP-01 certificate validation. Redirect with a 301 to the same host and path, and keep /.well-known/acme-challenge/ reachable.
- What Cache-Control should an HTML page have?
- no-cache, which permits caching but requires revalidation, paired with an ETag. That is a separate rule from fingerprinted static assets, which want public, max-age=31536000, immutable. Applying one policy to both is the usual mistake.
What this tool checks (17 rules)
- http.headers.cache-directives-conflicting — The caching instructions contradict each other
- http.headers.charset-missing — A text response does not declare its character encoding
- http.headers.compression-encoding-mismatch — The declared Content-Encoding may not match the body
- http.headers.compression-not-applied — A compressible response was sent uncompressed
- http.headers.content-type-missing — The response has a body but no Content-Type
- http.headers.deprecated-header-present — The response sends obsolete headers, one of them harmful
- http.headers.http3-not-advertised — No Alt-Svc header advertises HTTP/3
- http.headers.internal-address-disclosed — A response header leaks an internal address
- http.headers.no-cache-control — The response does not say how long it may be cached
- http.headers.no-validator — The response cannot be revalidated without downloading it again
- http.headers.vary-missing-accept-encoding — A compressed response does not vary on Accept-Encoding
- http.headers.vary-wildcard — Vary: * makes the response uncacheable by any shared cache
- http.reachability.error-status — The site's home page returns an error status
- http.reachability.http-closed — Plain HTTP is not served at all
- http.reachability.http-open-no-redirect — Plain HTTP does not redirect to HTTPS
- http.reachability.https-unreachable — The site does not answer over HTTPS
- http.reachability.slow-response — The server was slow to respond