Skip to content
TextArray1.41.0
100% local

HTTP header parser

Parse a pasted block of raw HTTP request or response headers into readable name/value pairs.

Input
Output
Related tools
cURL to code converterDeveloper tools
JWT decoderDeveloper tools
CSP header generatorDeveloper tools
i18n key diffDeveloper tools
TOML to JSON converterDeveloper tools
SQL to JSONDeveloper tools
HTTP header parser
Paste a block of raw HTTP headers — copied from browser dev tools, curl -i, a proxy log or an API doc — and this tool splits it into the first line (the request method and target, or the response status code) plus every header as a clean name/value pair. It saves the manual work of eyeballing a wall of "Name: value" lines to find the one header you actually care about.
Turn on "Expand compound headers" to break multi-directive headers like Cache-Control and Content-Security-Policy into one row per directive, so "no-cache, no-store, must-revalidate" becomes three separate, scannable entries instead of one long string you have to parse by eye. "Normalize header name casing" rewrites names to their conventional form (content-type becomes Content-Type) regardless of how the source sent them, since HTTP header names are case-insensitive on the wire but inconsistent in practice. Sort the list alphabetically to find a specific header fast in a long response, and switch the output between an aligned text table and JSON when you need the result to paste into a script instead of read by eye.
Turn on "Warn about missing security headers" to check the parsed headers against six commonly recommended ones — Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy — and list whichever aren't present. It's a quick sanity check while debugging a deployment, not a substitute for a full security audit.
Everything runs locally in your browser: the headers you paste, which can include cookies, tokens or internal hostnames, are never uploaded anywhere. Parsing handles both Windows (CRLF) and Unix (LF) line endings, tolerates old-style folded continuation lines, and stops at the first blank line — exactly where the HTTP spec says the body begins — so pasting a full response with its body attached is safe.
FAQ
Does it work with both requests and responses?
Yes. It recognizes a request line (method, target, HTTP version) or a status line (HTTP version, status code, reason phrase) automatically, and falls back to parsing plain header lines if neither is present.
What does "Expand compound headers" actually split?
Headers whose value is really a list of directives: Cache-Control and Permissions-Policy on commas, and Content-Security-Policy and Strict-Transport-Security on semicolons. Each directive becomes its own row under the same header name.
Which security headers does it check for?
Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy — six commonly recommended response headers. It only reports which are absent; it does not validate the value of any header that is present.
What happens to the body if I paste a full response?
Nothing — it's ignored. Parsing stops at the first blank line, which is where HTTP headers end and the body begins, so pasting a full curl -i or dev-tools capture is safe.
Is my pasted header data uploaded anywhere?
No. Parsing runs entirely in your browser — the headers, including any cookies or tokens they contain, never leave your device.