HTTP Header Parser — Request and Response Headers, Decoded Line by Line
HTTP Header Parser
Paste an entire HTTP request or response — the block
curl -v prints, or what the browser Network panel shows —
and every header line is decoded: the name, the value, a plain-English
sentence about what it does, and the document that defines it.
Set-Cookie is taken apart attribute by attribute
(Secure, HttpOnly, SameSite, Max-Age, Expires…),
Content-Type and Accept parameters are
expanded, and the block is audited for the classic structural
problems: obsolete folded lines, illegal characters, duplicate
headers and headers sent in the wrong direction. Everything runs
in your browser and nothing is uploaded.
Input
Automatically looks at the first line: a request line
(GET /path HTTP/1.1) means request, a status line
(HTTP/1.1 200 OK) means response, anything else is read
as a bare block of headers. The other choices force the direction,
which changes which warnings apply.
Parsed report
Nothing parsed yet. Paste a request or response block above and press Parse headers, or press Sample for a worked example.
Where to get a block worth parsing.
In a terminal, curl -v https://example.com/ 2>&1 prints the
request and the response with > and < prefixes —
strip those and paste. curl -sI https://example.com/ gives just the
response header block. In the browser, open developer tools, Network tab,
reload, select the document request and use Copy →
Copy response headers; for the request side use Copy as cURL
and read the flags. A plain block of Name: value lines with no
start line also parses — the direction checks are then relaxed.
Self-test
Re-runs the parser against fixed blocks: direction detection, both sample
pools, every Set-Cookie attribute rule (SameSite=None without Secure,
a non-numeric Max-Age, a broken Expires, an unknown attribute, a cookie
with no equals sign), obs-fold joining, illegal field names, duplicate
headers, direction mismatches and the negative paths. Nothing is sent anywhere.
What is an HTTP header?
In one sentence: an HTTP message is a start line, a block of
Name: value lines called headers, an empty line, and an optional
body — the headers carry everything about the message except the body
itself: who sent it, what it can accept, how it is cached, how it is
authenticated and what the sender wants back.
what format the body is in and which copy of it this is
Control headers
both, about the connection
Cache-Control, Connection, Via, Transfer-Encoding
how the message and the connection are handled on the way
Some headers are firmly one-directional: If-None-Match only ever makes sense in a request and Set-Cookie only ever in a response. Parsing in the wrong direction is one of the classic copy-paste debugging mistakes, which is why this page flags it.
The grammar of a header line
RFC 9110 defines a field line as field-name ":" OWS field-value OWS — a name made only of token characters (letters, digits and !#$%&'*+-.^_`|~), a colon with no space before it, and a value of visible characters, spaces and tabs. Header names are case-insensitive (content-type equals Content-Type); values are almost always case-sensitive. A line starting with a space or tab used to continue the previous header — obs-fold, obsolete since 2014: a proxy that unfolds it can change what the header means, so the parser here joins it but warns you it is there.
Common mistakes
Trusting X-Forwarded-For. It is added by every proxy on the path, and a client can forge the first hop. It tells you what a chain of proxies claims, not who is connected; treat it as a hint, and prefer a proxy you control overwriting it.
Reading the response headers only. Half of the interesting mistakes (a duplicated Accept, a missing Host, an authorization header aimed at the wrong host) live in the request, which the browser hides by default. Use Copy as cURL to see your own.
Merging Set-Cookie lines. Most duplicated headers may be combined with commas — Set-Cookie must not be, because the comma appears inside the value itself. Browsers treat each line as a separate cookie.
Expecting Content-Length to be the body size you wrote. It is the size after Content-Encoding is applied and only when the message is not chunked; a Transfer-Encoding: chunked response has no meaningful single length.
Judging headers by their X- prefix. The convention died in RFC 6648: X-Forwarded-For and X-Content-Type-Options are permanent de-facto standards, while plenty of non-X headers are experimental. Judge by the defining document, not the prefix.
FAQ
Is it safe to paste headers here? The parsing happens entirely in your browser and nothing is uploaded. That said, a copied header block is a fingerprint: cookies, authorization headers and the exact User-Agent together can identify you, so parse blocks you would not mind showing a colleague.
Why does my browser show headers like :status that this page calls errors? Those are HTTP/2 and HTTP/3 pseudo-headers — the binary framing layers replace the start line and Host with pseudo-fields. This page parses the classic HTTP/1.1 wire text; pseudo-headers are the same information after the protocol translated it.
What happened to X-XSS-Protection? It is deprecated: the auditor it drove caused security bugs of its own and browsers removed it. Its job belongs to a Content-Security-Policy — build one on the CSP generator and audit the whole set on the security headers checker.
How is a Set-Cookie attribute checked? Against RFC 6265: names and values are split at the first equals sign, attributes after the first semicolon, Expires must be a date in the cookie format, Max-Age digits, SameSite one of Strict/Lax/None — and None without Secure is rejected by current browsers, so it is called out.
Can I parse just a list of header lines? Yes — pick Header block only and paste without a start line. Direction checks are relaxed; everything else (structure, Set-Cookie, parameters) still runs.
