About HTTP Headers Viewer
HTTP headers are key-value pairs that accompany every request and response on the web, carrying metadata about the message: content type, caching directives, security policies, authentication tokens, encoding, and dozens of other concerns. Browsers, servers, CDNs, and intermediate proxies all read and write headers to coordinate behavior. Inspecting them is essential for diagnosing performance, caching, security, and integration issues.
This viewer fetches a URL and displays the response headers exactly as the server returned them. Common headers like Content-Type, Cache-Control, Content-Security-Policy, Strict-Transport-Security, and Set-Cookie are highlighted. The tool follows redirects by default, showing each step in the chain.
Some headers are particularly important for security and SEO. CSP (Content-Security-Policy) controls what resources a page can load. HSTS (Strict-Transport-Security) forces HTTPS. X-Frame-Options prevents clickjacking. Cache-Control influences how much traffic the server actually sees. Inspecting these on real responses helps verify configuration.
Why Inspect HTTP Headers
Most performance and security configuration on the web lives in headers rather than in HTML or JavaScript. CDN caching, browser caching, security policies, CORS, and HTTPS enforcement are all controlled by response headers. Inspecting actual responses confirms whether the configured headers are reaching clients.
Headers also help diagnose subtle bugs. A missing Content-Type triggers MIME sniffing. A wrong Cache-Control causes stale content or excessive load. A missing CSP allows unintended scripts. The viewer surfaces the actual headers so misconfigurations become visible.
Technical Details
HTTP/1.1 (RFC 7230) defines headers as case-insensitive key-value pairs separated by colons, with the value continuing to the end of the line. HTTP/2 (RFC 7540) and HTTP/3 use a binary framing format internally but the header semantics remain the same; viewers display them as if HTTP/1 syntax for readability.
Common response headers: Content-Type (MIME type and charset), Content-Length, Content-Encoding (gzip, br for compression), Cache-Control, ETag, Last-Modified, Set-Cookie, Server, Date, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Content-Security-Policy.
The browser's same-origin policy may prevent JavaScript-based viewers from reading certain headers (cookies and authentication headers in particular). Proxy-based viewers (a server fetches and reports back) avoid this limitation.
Frequently Asked Questions
- Why are some headers missing from my browser's developer tools?
- Browsers hide certain headers from JavaScript for security (Set-Cookie, authentication headers). Server-side viewers can show these. The Network tab in dev tools shows most response headers but not all.
- What's the difference between Cache-Control and ETag?
- Cache-Control specifies how long content can be cached (max-age=3600 means 1 hour). ETag is a unique identifier for the current version. ETags enable conditional requests: if the cached ETag matches, the server can return 304 Not Modified instead of resending the full body.
- Why does my CSP not block what I expected?
- CSP behavior depends on directive specifics (default-src, script-src, style-src, etc.) and the report-only mode flag. Inspect the actual header to confirm the policy you wrote is what is being served.
- Is HTTPS required for inspection?
- No, but strongly recommended. HTTP requests and responses can be intercepted and modified in transit; HTTPS prevents that.
- How do I check if HSTS is enabled?
- Look for the Strict-Transport-Security response header. Its value typically includes max-age and optionally includeSubDomains and preload.
- What should I do if Content-Type is missing?
- Browsers fall back to MIME sniffing, which can cause security issues. Configure your server to always send a correct Content-Type. The X-Content-Type-Options: nosniff header prevents browsers from overriding the declared type.
- Can I inspect headers from sites I do not own?
- Yes for public URLs. The headers are returned to anyone making the request. Cookies and authentication headers tied to your session are not exposed because the inspection request does not carry them.
- What about HTTP/3 specific headers?
- HTTP/3 retains the same header semantics as HTTP/1.1 and HTTP/2. The transport differs (QUIC instead of TCP) but the headers you see are the same.