HTTP Header Checker – Inspect Response Headers (HTTP/2 & HTTP/3)
Analyze HTTP response headers, security, caching, and CORS policies with detailed insights.
HTTP Header Inspector
HTTP Header Checker – Inspect Response Headers (HTTP/2 & HTTP/3)
Analyze HTTP response headers, security, caching, and CORS policies with detailed insights.
Features
- Real-time HTTP HEAD or GET inspection against any reachable URL, displaying all response headers in their raw form plus a categorized breakdown
- Security-headers audit with grade-based reporting: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection (deprecated, flagged) — explains each header's purpose and likely impact if missing
- Caching analysis: Cache-Control directives parsed (public, private, max-age, s-maxage, no-cache, no-store, must-revalidate, immutable, stale-while-revalidate), ETag and Last-Modified shown alongside, plus Surrogate-Control if present
- CORS analysis: Access-Control-* headers explained, with a checklist for preflight (OPTIONS) vs simple request handling. Highlights wildcard origins when credentials are also allowed (a common security mistake)
- Content-Type and encoding inspection: charset detection, gzip/brotli/deflate transfer-encoding, Vary header for cache-key implications, plus the response body's declared encoding vs sniffed
- Redirect chain trace: shows each 30x hop, the final URL, total redirect count, and any cycle (which would loop forever for a browser)
- Compare two URLs side-by-side to catch staging-vs-production header drift before it becomes a security incident
- Pure client-side: requests originate from your browser. CORS-restricted origins return only what the browser exposes; for those, install a browser extension that adds the URL to permitted origins or use a curl-equivalent CLI
How to use
- Enter the URL you want to inspect. The tool sends a HEAD request by default (no body downloaded); switch to GET if HEAD is rejected.
- Read the raw headers panel. Hover any header for a short description of its purpose.
- Open the Security tab for an audit of CSP, HSTS, X-Frame-Options, etc. Each missing header explains the risk (clickjacking, mixed content, etc.).
- Open the Caching tab to see if your CDN behavior matches expectations (public+max-age for assets, private+no-store for authenticated pages).
- For staging-vs-production drift detection, click Compare and enter the second URL — diff highlights changed/missing/added headers.
- Copy any header for sharing in a ticket or PR. The full output can also be downloaded as a .txt file.
Tips & Best Practices
- Run the security audit on every release; small CSP regressions are common when third-party scripts get added.
- For new sites, the baseline grade-A configuration is: HSTS with preload + CSP with no unsafe-inline + X-Frame-Options DENY + X-Content-Type-Options nosniff + Referrer-Policy strict-origin-when-cross-origin.
- Vary: Accept-Encoding is essential when CDN-caching compressed responses — without it, the CDN may serve a gzipped response to a client that asked for identity encoding.
- Use the Compare feature between staging and production after each deploy; CSP drifts catch real bugs more often than you'd expect.
- For CDN performance debugging, check the Age header (how long the response has been in cache) against your max-age to see if the CDN is honoring your directives.
FAQ
Why does the tool show fewer headers than curl shows?
Browsers (and therefore this tool) get a filtered set of response headers — Set-Cookie, Server, etc. are hidden by CORS policy unless the server includes them in Access-Control-Expose-Headers. For full header visibility, run curl -I directly. The tool shows everything the Browser Fetch API exposes.
What's the difference between HSTS and HSTS preload?
HSTS (HTTP Strict-Transport-Security) is a response header telling browsers to use HTTPS for max-age seconds. HSTS preload is hardcoded in browsers (via the hstspreload.org list) so even the very first request never tries HTTP. The audit flags HSTS without preload; if you want preload, submit your domain to hstspreload.org.
Why is X-XSS-Protection flagged as bad?
It was the IE/Chrome XSS-filter directive (X-XSS-Protection: 1; mode=block), but the filter was buggy and could be exploited. Modern browsers (Chrome 78+, Firefox, Safari) removed it entirely. Use CSP frame-ancestors instead for clickjacking; CSP script-src for XSS. The audit flags X-XSS-Protection as not adding security.
How does the CSP analyzer work?
The CSP header is parsed by directive: default-src, script-src, style-src, img-src, etc. The analyzer highlights unsafe-inline and unsafe-eval (script execution risks), wildcards in script-src (worth scrutiny), missing report-uri (no telemetry on violations), and the absence of frame-ancestors (clickjacking).
What's the right Cache-Control for HTML pages?
For authenticated pages: private, no-store, max-age=0. For static HTML behind a CDN: public, max-age=300 with ETag/Last-Modified for conditional revalidation. For SPA shell HTML: public, max-age=0, must-revalidate so the shell updates without requiring users to clear cache. The analyzer shows the directives but doesn't recommend specific values — depends on your use case.
Why is wildcard CORS with credentials a problem?
Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true is rejected by browsers (it would let any origin read authenticated responses), but the server is still misconfigured if it sets both. The audit flags this explicitly — either remove credentials or list specific origins.
Can I check internal/intranet URLs?
Yes if your browser can reach them. The fetch goes from your browser, so internal corporate URLs work as long as you're on the VPN. Localhost development URLs work too. For headers that CORS strips, you may need a non-browser tool.
Is my URL or its response logged anywhere?
No. The fetch happens from your browser to the target; we don't observe the URL or response. The Compare feature stores nothing across sessions; each visit starts fresh.