HTTP Header Inspector
Paste raw HTTP request or response headers and get a structured, categorised table with descriptions for every header. Covers security, caching, CORS, auth, content, and custom headers.
Paste Raw HTTP Headers
Category Legend
HTTP Header Categories Explained
HTTP headers are grouped into functional categories based on their purpose. This inspector classifies each header automatically so you can quickly assess the security posture, caching behaviour, and CORS configuration of any HTTP response without memorising hundreds of individual header names.
Security
Protect against XSS, clickjacking, MITM, and data leaks.
Strict-Transport-SecurityContent-Security-PolicyX-Frame-OptionsX-Content-Type-OptionsReferrer-PolicyPermissions-PolicyCaching
Control CDN and browser cache behaviour and freshness.
Cache-ControlETagLast-ModifiedExpiresAgeVaryCORS
Enable and restrict cross-origin browser requests.
Access-Control-Allow-OriginAccess-Control-Allow-MethodsAccess-Control-Allow-HeadersAccess-Control-Expose-HeadersAuth
Bearer tokens, basic auth, session cookies, and challenges.
AuthorizationWWW-AuthenticateCookieSet-CookieContent
Describe the format, size, and encoding of the body.
Content-TypeContent-LengthContent-EncodingContent-DispositionCustom / Infra
Tracing IDs, proxied IPs, and vendor-specific extensions.
X-Request-IdX-Forwarded-ForX-Real-IPX-Powered-ByEssential Security Headers Checklist
Every public-facing web application should include these security response headers. Paste your response headers into the inspector above to instantly see which are present and which are missing.
| Header | Recommended Value | Protects Against |
|---|---|---|
| Strict-Transport-Security | max-age=63072000; includeSubDomains; preload | Protocol downgrade, MITM |
| X-Content-Type-Options | nosniff | MIME sniffing attacks |
| X-Frame-Options | DENY or SAMEORIGIN | Clickjacking |
| Content-Security-Policy | default-src 'self'; … | XSS, injection |
| Referrer-Policy | strict-origin-when-cross-origin | URL leakage |
| Permissions-Policy | camera=(), microphone=() | Feature abuse |
How to Capture HTTP Headers for Inspection
There are several ways to capture raw HTTP headers for pasting into this tool. In Chrome or Firefox DevTools, open the Network tab, click any request, select the Headers tab, and copy the raw headers from the Request Headers or Response Headers sections. With cURL, use curl -I https://example.com to fetch only the response headers, or curl -v https://example.com for full verbose output including request and response headers. With httpie, use http HEAD https://example.com. You can also paste headers captured from security tools like Burp Suite or OWASP ZAP proxy.
Frequently Asked Questions
What are HTTP headers and why do they matter?
HTTP headers are metadata key-value pairs transmitted at the beginning of every HTTP request and response. They control a wide range of behaviours: how the browser caches a response, what content formats are accepted, which origins are allowed (CORS), how the browser should enforce security policies (CSP, HSTS), how authentication credentials are presented, and much more. Understanding headers is essential for debugging API calls, diagnosing performance issues, auditing security posture, and building correct web applications.
What is the difference between request headers and response headers?
Request headers are sent by the client (browser, cURL, fetch) to the server and describe the request — what content the client accepts, authentication tokens, cookies, the origin of the request, and client capabilities. Response headers are sent by the server back to the client and describe the response — content type, caching rules, security policies, CORS permissions, and set-cookie instructions. Some headers like Content-Type and Cache-Control appear in both directions with different meanings.
Which HTTP headers are most important for security?
The most security-critical headers are: Strict-Transport-Security (HSTS) — forces HTTPS for a defined duration; Content-Security-Policy (CSP) — restricts allowed resource sources to mitigate XSS; X-Frame-Options or CSP frame-ancestors — prevent clickjacking; X-Content-Type-Options: nosniff — stops MIME sniffing attacks; Referrer-Policy — controls what referrer data is leaked; and Permissions-Policy — restricts access to browser APIs like camera and geolocation. A missing or misconfigured security header is one of the most common vulnerabilities in web applications.
What does Cache-Control: no-store vs no-cache mean?
Cache-Control: no-store instructs every cache (browser, CDN, proxy) to never store any part of the request or response. It is the most strict caching directive and is appropriate for sensitive data like bank transactions or health records. Cache-Control: no-cache means the cache may store the response, but must revalidate with the origin server before serving it to the client (using ETag or Last-Modified). This allows caching while ensuring freshness, making it useful for dynamic pages that change but are still cacheable. Pragma: no-cache is the legacy HTTP/1.0 equivalent of Cache-Control: no-cache.
How do CORS headers work between a browser and server?
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts JavaScript from making requests to a different origin unless the server explicitly permits it. For a simple cross-origin request, the browser includes an Origin header, and the server must respond with Access-Control-Allow-Origin matching that origin (or '*'). For requests with custom headers or non-simple methods, the browser first sends an OPTIONS preflight request. The server responds with Access-Control-Allow-Methods, Access-Control-Allow-Headers, and optionally Access-Control-Max-Age to cache the preflight result. If credentials (cookies, auth headers) are needed, Access-Control-Allow-Credentials: true must be set and Access-Control-Allow-Origin must be a specific origin, not '*'.