HTTP Header Parser

How to use it

1. Copy the raw headers from devtools, a log file or a curl output — one Name: value per line.
2. Paste them into the input box; parsing runs as you type.
3. Read the table: each row shows the header name, its value and a note for well-known headers.
4. The request line (GET / HTTP/1.1) or status line (HTTP/1.1 200 OK) is shown as-is in the first row.
5. Lines without a valid Name: value shape are listed separately under "could not be parsed" — nothing is dropped silently.

Common use cases

• Debugging API calls — checking whether Authorization, Content-Type or CORS headers were actually sent.
• Inspecting caching behaviour — reading Cache-Control, ETag and Expires pairs from a response.
• Learning HTTP — pasting an example from a tutorial and seeing each header explained in plain language.
• Writing curl or fetch code — copying header blocks from captured traffic and confirming each line is well-formed.

Why it stays private

Parsing is plain string work in your browser. Header text is never uploaded — useful, since headers often contain cookies, tokens or internal hostnames.

FAQ

Q: Does it understand multi-line (folded) headers? A: No. Each line must be a single Name: value pair. Folded headers were deprecated in HTTP/1.1, so modern captures rarely contain them.

Q: What happens to lines that are not headers? A: They are kept and shown verbatim in a separate "could not be parsed" list. The tool reports rather than guesses.

Q: Are header names treated case-insensitively? A: Yes for the built-in notes — Content-Type and content-type get the same note. The original casing of your input is preserved in the table.