HTTP Headers to JSON

When something goes wrong between a browser, a proxy and a server, the headers tell the story. They show up in developer tools, in curl output, in logs and in bug reports as blocks of text, one header to a line. Converting them to JSON makes them searchable, easy to compare and ready to paste into a test or a script.

What the page recognises

Paste a block of text and the page looks at its first line. A line such as POST /api/v2/orders?id=42 HTTP/1.1 is a request line, and the page extracts the method, the path, the query string as an object and the protocol version. A line like HTTP/1.1 404 Not Found is a status line, and the status code and reason are shown. If neither pattern matches, the whole text is treated as a plain list of headers. Lines that begin with > or < are cleaned, which is how curl -v marks outgoing and incoming headers.

Header names and repeated headers

Header names are case-insensitive under RFC 9110, so Content-Type and content-type are the same field, and lower-casing them gives JSON keys that are easy to look up. HTTP/2 even requires lower case. When a header appears several times, the standard says the values can be combined into one comma-separated list, and the default option does that. Choose “Keep as an array” if you want each occurrence separately, which preserves the structure when a value can itself contain commas.

Cookies

A Cookie header holds name and value pairs separated by semicolons, and the page splits it into an object so you can see each cookie. Set-Cookie works differently: each header sets one cookie, with attributes such as Path, Max-Age, Secure and HttpOnly. The page parses them into a name, a value and an attribute object, and does not merge them. Be careful with real cookies and authorisation headers; they can log someone in. This page keeps your text in memory only and never stores or sends it.

Using the page

Paste into the left box. The JSON appears on the right and a summary panel above lists the method, path, query, version or status, the number of headers and any cookies. Warnings appear for lines that are not valid headers, for example a line without a colon, so you can see what was skipped. Options persist in your browser, but the pasted text does not.

A worked example

The Sample button loads a POST request to /api/v2/orders with query id=42 and expand=items. The summary shows the method POST, the path, the query as {“id”:“42”,“expand”:“items”}, the version HTTP/1.1, nine distinct headers and two cookies, session and theme. The two X-Forwarded-For lines are joined into one value, 203.0.113.7, 198.51.100.4, because the default is to join repeated headers. The output keys are lower-case, such as content-type and accept-language.

Limits

The parser reads text in HTTP/1.x style. It cannot read binary HTTP/2 or HTTP/3 frames, so copy headers from developer tools in their text form. It does not validate values against each header’s own grammar, check that required headers are present, or follow redirects. Obsolete line folding is joined, but unusual whitespace is kept as it is. Large dumps work, but the page treats the text as one message, so paste a single request or response at a time.

Related tools

• cURL to Fetch turns a request with its headers into code.
• HAR to cURL extracts a recorded request from a network trace.
• Query String to JSON expands the query part in more detail.
• User Agent Parser interprets the User-Agent header.