HTTP Header Parser
Max 1 MB · Parses automatically as you type · Accepts a full request/response block or a bare header list
| Name | Value | Description |
|---|
Processed entirely in your browser — nothing is sent to a server.
An HTTP request or response is, underneath the browser’s or client’s own presentation of it, just a block of text: a start line, followed by a series of Name: value header lines, followed by an optional body. This tool parses that raw text block — pasted from browser DevTools, a curl -v capture, a proxy log, or written by hand — into a readable table, with the start line summarized separately from the headers and a one-line explanation attached to every header this tool recognizes.
Start-line detection happens first, and is deliberately optional. A line shaped like GET /api/users HTTP/1.1 is recognized as a request line and broken into its method, path, and HTTP version; a line shaped like HTTP/1.1 200 OK is recognized as a status line and broken into its version, status code, and reason phrase. If the first line matches neither shape, nothing is treated as an error — the whole input is simply parsed as a bare header list, which is exactly what you get copying “Response Headers” out of a browser’s Network panel.
Header parsing follows the pragmatic rules real-world HTTP text actually follows, not just the strict grammar. A header’s value is everything after its first colon, trimmed of surrounding whitespace — so a Date header’s own colons, or a Location header pointing at a URL with an explicit port, are never truncated. Header names are matched case-insensitively (content-type and Content-Type are the same header) but displayed exactly as you typed them. A header that repeats — most commonly Set-Cookie, which is genuinely meant to appear once per cookie — is listed as a separate row per occurrence, never collapsed down to just the last one. Legacy line-folding (a continuation line starting with a space or tab, still occasionally seen in older captures) is unfolded into the header it belongs to rather than rejected.
Every recognized header — Content-Type, Authorization, Cache-Control, the Set-Cookie and CORS families, Content-Security-Policy, and several dozen others — gets a one-line, plain-English explanation next to it. An unrecognized header (a custom X- header, for instance) still parses and displays correctly; it simply has no description attached. Parsing stops at the first blank line, the same place a real HTTP message’s own headers end, so pasting a full request or response — body included — never trips an error on the body’s own content.
Examples
- Debugging an API's Authorization flow — paste a captured request and immediately see its Bearer token isolated in its own row; follow up in JWT Decoder to inspect the token's claims, since an Authorization header commonly carries a JWT.
- Auditing Set-Cookie and cache headers on a response — paste a raw response block with several Set-Cookie lines plus Cache-Control/ETag/Expires, and see every cookie listed individually (never merged) alongside a plain-English explanation of what each caching header actually controls.
- Reading a CORS preflight response — paste the Access-Control-Allow-Origin/-Methods/-Headers/-Credentials block a browser's DevTools shows for an OPTIONS request, and get each directive explained in place instead of having to look each one up separately.
Frequently asked questions
Are my headers sent anywhere?
Authorization bearer token, a session cookie, or an API key, and none of it ever leaves your device.What happens with duplicate header names, like two Set-Cookie lines?
Set-Cookie, which is set once per cookie and is genuinely meant to repeat; collapsing duplicates down to "the last one wins" would hide real cookies a server is setting.Are header names case-sensitive?
content-type, Content-Type, and CONTENT-TYPE all name the same header. This tool preserves whatever casing you pasted for display, but looks up its one-line description case-insensitively, so a lowercase or all-caps header still gets annotated correctly.Does it work with just a plain list of headers, with no request or status line?
Name: value lines — no GET ... HTTP/1.1 or HTTP/1.1 200 OK first — is parsed the same way, just without a start-line summary above the table. The parser only shows a Request or Response summary when it actually recognizes one.What if I paste a full response, body included?
curl -v or browser DevTools capture works without trimming it first.