Skip to main content
HTTP & Developer Utilities

HTTP Headers Parser

Paste raw HTTP request or response headers and instantly convert them to clean JSON, a sortable table with plain-English explanations, validation warnings, and a missing-security-header check. 100% client-side — nothing you paste ever leaves your browser.

Examples:

How to Parse HTTP Headers Online

An HTTP headers parser takes the raw Name: Value block from an HTTP request or response — the kind you copy from browser DevTools, curl -I, curl -v, or server logs — and turns it into structured data you can actually work with. Paste the block into the box above and click Parse Headers:

  1. Detect — the parser recognizes a status line (HTTP/1.1 200 OK), a request line (GET / HTTP/1.1), or a bare header block automatically.
  2. JSON — get clean, pretty-printed JSON. Duplicate Set-Cookie lines stay as an array; other duplicates are combined per RFC 9110.
  3. Table — every header gets a category (Content, Caching, CORS, Security, Auth, Cookies…) and a plain-English explanation.
  4. Validate — malformed lines, obsolete folded headers, and unexpected duplicates are flagged with line numbers.
  5. Harden — missing Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and weak CORS setups are surfaced as a checklist.

Convert HTTP Headers to JSON

Converting HTTP headers to JSON is the fastest way to feed them into scripts, tests, and documentation. Header names are case-insensitive per the HTTP specification, so Content-Type and content-type describe the same field — this tool groups them under the first-seen casing and warns you about the duplicate. The one exception it never merges is Set-Cookie: each line is a separate cookie with its own attributes (Path, Domain, Max-Age, Secure, HttpOnly, SameSite), broken out in the Set-Cookie section.

HTTP Headers Explained: Reference Categories

Every known header in the result table is tagged with one of these categories and a short explanation:

  • Content — Content-Type, Content-Length, Content-Encoding, Content-Disposition
  • Caching — Cache-Control, ETag, Expires, Last-Modified, Vary
  • CORS — Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Credentials
  • Security — Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
  • Auth — Authorization, WWW-Authenticate, Proxy-Authorization (values masked by default)
  • Cookies — Set-Cookie, Cookie
  • Transport / Request — Host, Date, Location, Transfer-Encoding, User-Agent

Works With curl and DevTools Output

You can paste a curl headers transcript directly: the parser skips leading blank lines, stops at the first empty line (so response bodies are ignored), and reports non-header lines from curl -v (like * Connected to or > GET /) as skipped lines instead of failing. For a quick start, try the worked examples above — including a CORS API response, a cookie-heavy response, and a deliberately malformed block that shows the validator in action.

Related tools: cURL GET Request Generator, Online cURL Tester, JSON Parser, and the Email Header Analyzer for message headers.

Frequently Asked Questions

They parse two different protocols. This tool parses HTTP headers: the Name: Value block from an HTTP request or response (Content-Type, Cache-Control, Set-Cookie, Authorization, CORS headers, and so on). The email header analyzer parses email message headers such as From, To, Subject, and Received hops from an .eml file or raw email source. The syntax looks similar, but the header vocabularies and the rules for duplicates are completely different, so they are separate tools.
Because people routinely paste real credentials when debugging. Displaying a live Bearer <redacted> or Basic password in the result table is how secrets end up in screenshots and shared links. This tool masks Authorization and Proxy-Authorization values by default (showing only the scheme, e.g. Bearer) while keeping the real value in your input box. A per-row reveal toggle shows it when you actually need it.
No. All parsing, validation, and security analysis run in JavaScript inside your browser. There is no upload, no API call, and nothing is stored or logged. You can even disconnect from the network after the page loads and the parser keeps working.
No, and any tool that claims otherwise from pasted text is overselling. This is a static analysis of the text you paste: it flags the absence of headers like Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and X-Content-Type-Options, and warns about weak values such as a wildcard CORS origin combined with credentials. It cannot probe your server, test every page, or prove you are exploitable. Treat the findings as a checklist, not a verdict.
Per RFC 9110, most duplicate headers can be combined into one comma-separated value, but Set-Cookie is the famous exception: each Set-Cookie line is a separate cookie and must never be merged. The parser keeps every occurrence in order, always renders Set-Cookie as an array in the JSON output, breaks each cookie into name, value, and attributes (Path, Domain, Max-Age, Secure, HttpOnly, SameSite), and flags unexpected duplicates of other headers as warnings.
Folding is an obsolete convention where a long header value continues on the next line, indented with a space or tab. It was deprecated by RFC 7230 because it creates parsing ambiguity and even security issues (request smuggling). This tool still understands folded lines so old logs and email-style exports parse correctly, but it flags each one as a warning so you can replace it with a single-line header.
HTTP header field names are defined as case-insensitive by the HTTP specifications (RFC 9110). Content-Type, content-type, and CONTENT-TYPE all mean the same header. The parser groups headers by their lowercase name, preserves the original casing of the first occurrence for display, and flags exact duplicates so you can see when casing varies across lines.
Yes. The parser ignores leading blank lines, detects a status line (HTTP/1.1 200 OK) or request line (GET / HTTP/1.1) automatically, and stops at the first empty line, so a curl -v transcript with its < response markers and a DevTools 'copy as raw' block both parse. Lines that are not headers, such as the * Connected to or > GET / lines from curl -v, are reported as skipped rather than crashing the parse.

Free tool by NRTechStudio