How to use HTTP Headers Parser
- Copy headers from curl -i, DevTools or a proxy log and paste them into the input.
- Review the summary and the categorised table; hover the explanation column to understand each header.
- Work through the Findings list to harden caching and security settings.
- Download the table as CSV to attach to a bug report or security review.
HTTP Headers Parser features
- Understands raw header blocks, full HTTP messages with a status/request line, HTTP/2 pseudo-headers and folded continuation lines
- Categorises every header: caching, security, CORS, content, cookies, authentication, request, response
- Explanations for more than 120 well-known headers and sensible fallbacks for X-, Sec- and CF- prefixes
- Per-header warnings: weak HSTS, unsafe CSP, insecure cookies, contradictory Cache-Control, exposed server versions
- Message-level findings: missing security headers for HTML responses, duplicate headers, Host missing on HTTP/1.1
- Summary of status, content type, caching policy and cookies; body shown separately when present
HTTP Headers Parser example
Parse a response with an insecure cookie
Input:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=abc123; Path=/
X-Powered-By: Express 4.19.2Output:
Message type: HTTP response · Status: 200 OK · Headers: 3
Set-Cookie → Cookies: Missing Secure attribute. Missing HttpOnly. Missing SameSite.
X-Powered-By → Security: Version number exposed; remove it to reduce fingerprinting.
Findings: Missing Strict-Transport-Security · Missing X-Content-Type-Options · Missing Content-Security-Policy for an HTML document · No charset declaredFrequently asked questions about HTTP Headers Parser
Where do I get raw headers to paste?
Run curl -i https://example.com in a terminal, or in browser DevTools open the Network tab, select a request and use "Copy request headers" / "Copy response headers". Both formats are understood, including HTTP/2 pseudo-headers such as :authority.
Does the tool understand a full HTTP message with a body?
Yes. A status line (HTTP/1.1 200 OK) or request line (GET /path HTTP/1.1) is recognised, headers are read until the first blank line and everything after it is shown as the body.
What warnings does it produce?
Missing HSTS, nosniff, CSP or clickjacking protection on responses; cookies without Secure, HttpOnly or SameSite; contradictory Cache-Control directives; wildcard CORS with credentials; exposed server versions; duplicate headers; and invalid values for well-known headers.
Are my headers sent to a server?
No. Parsing runs entirely in your browser. Tokens in Authorization or Cookie headers never leave your device.
Technical notes
Header names are validated against the RFC 9110 token grammar, values are trimmed and obsolete line folding (obs-fold) is joined. The direction of a bare header block is inferred from tell-tale headers (Host, User-Agent, Cookie for requests; Set-Cookie, Server, ETag for responses).
Security findings mirror the OWASP Secure Headers Project recommendations and the Mozilla Observatory checks; they are advisory and depend on the kind of resource being served.