What the HTTP Headers Decoder does
Raw HTTP headers are compact and cryptic. A single line like `Content-Security-Policy: default-src 'self'; script-src 'nonce-abc123'` is powerful but hard to parse at a glance, especially when you are debugging a CORS issue or reviewing a security policy. The HTTP Headers Decoder at /developer-tools/validators/http-headers-decoder takes a block of raw headers, splits each line into name and value, and annotates every recognized header with a short description explaining what it controls.
The tool recognizes over 60 common request and response headers spanning caching, security, content negotiation, authentication, and proxying. Unknown headers are still parsed and displayed but without annotation, so the tool works with any header block even if it contains custom `X-` headers.
Supported header categories
Security headers: `Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options`, `X-Frame-Options`, `X-XSS-Protection`, and `Permissions-Policy`.
Caching headers: `Cache-Control`, `ETag`, `Last-Modified`, `Expires`, and `Vary`.
Content headers: `Content-Type`, `Content-Length`, `Content-Encoding`, `Content-Disposition`, and `Content-Range`.
Authentication and authorization: `Authorization`, `WWW-Authenticate`, `Proxy-Authorization`, and `Proxy-Authenticate`.
Proxy and routing: `X-Forwarded-For`, `X-Forwarded-Proto`, `X-Forwarded-Host`, `Forwarded`, and `Via`.
CORS headers: `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers`, `Access-Control-Expose-Headers`, and `Access-Control-Max-Age`.
Multi-line header folding (RFC 7230)
HTTP/1.1 allows long header values to span multiple lines using a continuation: any line that starts with whitespace is treated as a continuation of the previous header's value. This is defined in RFC 7230 and is common in `Set-Cookie` headers and complex `Content-Security-Policy` values. The decoder detects these continuation lines (by checking for leading whitespace) and folds them into the parent header's value, so you see the complete value in one place rather than split across lines.
This folding is invisible when you copy-paste from browser DevTools, but it appears in raw HTTP traces from tools like `curl -v`, `tcpdump`, or server access logs. The decoder handles both folded and unfolded input transparently.
Debugging CORS with the decoder
Cross-Origin Resource Sharing errors are among the most common and frustrating issues in web development. The browser's console tells you that a request was blocked, but the actual cause is buried in the response headers. Paste your server's response headers into the decoder and check these fields: `Access-Control-Allow-Origin` must match the request's origin or be `*`, `Access-Control-Allow-Methods` must list the HTTP method you are using, and `Access-Control-Allow-Headers` must include any custom headers your request sends.
The decoder annotates each CORS header with its purpose, so you can quickly spot a missing or misconfigured header without consulting MDN. For HTTP status code reference, see /blog/http-status. For JWT token inspection, see /blog/jwt-decoder. For URL encoding in headers, see /blog/url-encode-decode.
Recognized headers reference table
| Header | Category | Purpose |
|---|---|---|
| Content-Type | Content | MIME type of the response body |
| Cache-Control | Caching | Directives for caching behavior |
| Strict-Transport-Security | Security | Enforces HTTPS connections |
| X-Forwarded-For | Proxy | Client IP through proxies |
| Access-Control-Allow-Origin | CORS | Allowed origins for cross-origin requests |
| Authorization | Auth | Credential scheme and token |
| Content-Security-Policy | Security | Controls resource loading sources |
Step-by-step: parsing headers
Copy the raw headers from your browser DevTools Network tab, a `curl -v` trace, or a server log.
Paste them into the input area. One header per line in `Name: Value` format.
Click Parse headers. Each line is split into name and value and annotated.
Click the copy button on any row to grab the `Name: Value` pair.
For building Content-Security-Policy headers, see /blog/csp-builder.
Request headers vs response headers
The decoder does not require you to specify whether the headers are from a request or a response. Many headers are valid in both directions (for example, `Content-Type` appears in requests with POST bodies and in all responses). Some are direction-specific: `User-Agent` and `Authorization` are request-only, while `Set-Cookie` and `Server` are response-only. The annotation text indicates the typical direction, but the parser itself is format-agnostic. It simply splits on the first colon and looks up the name.
Privacy: local parsing only
This is critical because headers frequently contain `Authorization: Bearer <token>` lines with live access tokens. A server-side parser would receive those tokens. By keeping parsing client-side, EasyDevTools ensures your credentials stay on your device. Visit /about for more on our privacy approach.
Frequently asked questions
Q: How many headers are recognized?
A: Over 60 common request and response headers, including Authorization, Content-Type, Cache-Control, CSP, HSTS, and X-Forwarded-For.
Q: Does it handle multi-line headers?
A: Yes. RFC 7230 continuation lines (starting with whitespace) are folded into the previous header value.
Q: Does it fetch anything?
A: No. Headers are parsed locally with no outbound network call.
Q: Can I use this to debug CORS?
A: Yes. Paste the response headers and check Access-Control-Allow-Origin, Allow-Methods, and Allow-Headers.
