HTTP Headers Parser
Paste raw HTTP request or response headers to turn them into ordered structured data, preserve repeated fields, and surface malformed lines or message-framing patterns that deserve attention.
Paste headers from browser DevTools, curl, an API client, a proxy, or a server log.
0 lines
Parsed Header Data
The ordered field list is the safest view when duplicates or protocol details matter.
Ordered fields, grouped values, start-line details, and diagnostics will appear here.
Raw headers can contain credentials
Authorization tokens, API keys, Cookie, and Set-Cookie values can grant access to accounts or services. Parsing stays in your browser and no header-parsing API receives the pasted block, but copied output remains sensitive. Site-wide analytics or advertising scripts, if enabled, are separate from this parsing operation.
Turning a Raw Header Block Into a Debugging Trail
HTTP headers are most useful when you read them as evidence of what happened between a client, an intermediary, and a server. One line can explain why a response was cached, another why the browser redirected, another why authentication failed, and another which representation was actually returned.
Original field order and repeated values need to stay visible because that is often the information lost first when headers are converted into a simple object. A grouped view is convenient for scanning; the ordered list is safer when duplicates, cookies, proxies, or message framing are involved.
Follow the Clues in This Response
HTTP/1.1 302 Found Location: https://example.com/welcome?name=Sneha Cache-Control: no-store Set-Cookie: session=abc123; Path=/; Secure; HttpOnly
The first line says this is a 302 response. Location provides the redirect target. Cache-Control asks caches not to store the response. Set-Cookie asks the browser to create or update a cookie. That small block already tells you much more than the status code alone.
High-Value Fields to Recognize Quickly
Content-Type
Tells the receiver how to interpret the message content, such as JSON, HTML, CSS, or an image.
Location
Commonly identifies a redirect destination or a resource URI, depending on response status.
Cache-Control
Controls how browsers and intermediaries may cache or reuse a response.
Authorization
Carries credentials or tokens and should be treated as sensitive.
WWW-Authenticate
Describes the authentication challenge associated with a 401 response.
Cookie / Set-Cookie
Cookie sends stored values with a request; Set-Cookie asks the browser to store state from a response.
Repeated Fields Cannot Always Be Flattened Safely
HTTP field names are case-insensitive, but repeated values do not all share one universal merge rule. Some field definitions allow a combined list. Others, especially Set-Cookie, need separate field values. Cookie also has protocol-specific handling in HTTP/2 and HTTP/3.
Reducing the block to a last-value-wins object would lose that evidence. Ordered source fields and a separate grouped view keep both representations available. RFC 9110 explains when repeated field lines can be recombined and calls out Set-Cookie as a special case.
The Blank Line Is a Real Boundary
In HTTP/1.x text form, an empty line separates the header field section from the message body. If a curl -i capture or proxy trace also contains HTML, JSON, or another body, the non-empty lines after that boundary are counted as trailing text rather than treated as more header fields. A chunked trailer section is not reconstructed from pasted body text.
Content-Length and Transfer-Encoding Deserve Extra Attention
HTTP/1.x recipients must agree on where one message ends and the next begins. Conflicting Content-Length values, or an ambiguous combination of Content-Length and Transfer-Encoding, are security-sensitive because different intermediaries can interpret message boundaries differently.
Suspicious framing text can be surfaced from a pasted field section, but request-smuggling analysis still depends on the exact bytes and the behavior of every intermediary in the path. RFC 9112 defines the HTTP/1.1 message-length precedence rules behind these warnings.
Why HTTP/2 and HTTP/3 Captures Look Different
HTTP/2 and HTTP/3 use pseudo-header fields such as :method, :path, :authority, and :status instead of the textual request/status lines used by HTTP/1.x. Pseudo-headers have stricter ordering, duplication, required-field, lowercase-name, and connection-specific-field rules. Those rules are defined in RFC 9113 for HTTP/2 and RFC 9114 for HTTP/3. Extended CONNECT adds :protocol through RFC 8441, with HTTP/3 WebSocket use carried forward by RFC 9220.
Browser DevTools may show these fields in readable text even though the wire format is compressed. Readable field text is enough for structural inspection, but it is not an HPACK, QPACK, or binary-frame decoder.
Obsolete Line Folding Can Hide What a Field Contains
Older HTTP syntax allowed a field value to continue on an indented next line. Modern senders should not generate that obs-fold form. When it appears, joining the continuation with one space makes the value readable while still reporting that the source used obsolete syntax.
Questions the Header Block Can Answer
- Compare browser and API-client responses when only one client has a caching or authentication problem.
- Check whether a redirect really includes the expected Location field.
- Confirm that an API returned application/json rather than HTML or a generic binary type.
- Inspect several Set-Cookie fields without losing one to object-key overwriting.
- See which fields were added or changed by a CDN, reverse proxy, gateway, or origin server.
- Spot malformed field names, whitespace-before-colon, control characters, or suspicious HTTP/1.x framing values.
Structure Is Not the Same as Full Field Validation
Individual fields can have complex grammars of their own. Content Security Policy, Cache-Control, CORS, signatures, authentication challenges, Structured Fields, cookies, and content negotiation each need dedicated rules for deep validation. Preserving the raw field-section structure is a different job from fully validating every registered field.