Where do I get raw headers to paste in?
Browser DevTools (Network tab → click a request → Headers), or run curl -I <url> in a terminal.
HTTP Header Parser
Raw HTTP headers
EmptyName: value per line
Parsed headers
Paste raw HTTP headers to see them broken out line by line.
No resultRFC 9110 names
About this HTTP Header Parser
Parse HTTP request and response headers into structured information.
Paste one Name: value pair per line — the raw block you get from curl -i or devtools works as is, start line included. Both forms are read: a response status line (HTTP/1.1 301 Moved Permanently) and a request line (GET /path HTTP/1.1). Recognised headers pick up a category and description; anything else is still parsed, just without the reference notes. Request vs response is detected automatically — conclusively when a start line is present — and only a response is checked against a curated list of recommended security headers, scored on the ones its status code can actually use. Cookie, Content-Security-Policy, and CORS headers get their own structured breakdown below the raw list.
FAQ
Does it flag missing security headers (CSP, HSTS, X-Frame-Options)?
Yes — a response's headers are checked against a curated list of recommended security headers (CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and the Cross-Origin-* headers), each shown as present or missing with an overall letter grade. The scorecard only appears once the input is positively identified as a response, and the tool says which rule ruled it out when it doesn't: request headers aren't measured against a list of headers a server sends, a set whose direction can't be determined isn't assumed to be a response, and a 1xx is an interim reply whose security headers belong on the final response that follows it.
Why doesn't my 301 redirect get marked down for missing CSP?
Because no document is rendered from a redirect, so CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy and the Cross-Origin-* headers have nothing to govern there — adding them to a 3xx has no effect. Those checks are shown as n/a and left out of the score, and the same applies to 204 and 304 responses. HSTS is still scored, since it's a connection-level directive and an http-to-https redirect is exactly where it belongs. This narrowing needs the status line: paste the headers without it and the full checklist is used, because Location on its own isn't proof of a redirect.
Does it parse both request and response header formats?
Yes, including the first line of either. A response status line (HTTP/1.1 200 OK, HTTP/2 404) and a request line (GET /path HTTP/1.1, OPTIONS * HTTP/1.1, CONNECT host:443 HTTP/1.1) are both parsed and reported, so curl -i output and DevTools's "Copy request headers" / "Copy response headers" all work as pasted, with nothing to strip first. Whichever one is present settles the request/response question outright, since a status line can't appear in a request and a request line can't appear in a response. A start line on its own is valid input too. Without one, direction is inferred from which header names show up, and reads as unclear when they don't agree.
Why are there multiple Set-Cookie lines?
Set-Cookie is the one header that can't be comma-joined like other duplicates — each instance must stay on its own line, or the values get mangled.
Are header names case-sensitive?
No — HTTP header names are case-insensitive per spec.
Is my header data sent anywhere?
No, parsing happens entirely in your browser.
Related tools