Web Tools
HTTP Header Parser
Parse and inspect raw HTTP header fields locally.
Start line
HTTP/1.1 200 OKParsed fields
4 header fields| Field name | Value | Normalized name |
|---|---|---|
| Content-Type | text/html; charset=utf-8 | content-type |
| Cache-Control | public, max-age=3600 | cache-control |
| ETag | "abc123" | etag |
| Set-Cookie | theme=dark; Secure; SameSite=Lax | set-cookie |
Parsing happens locally. This tool checks field-line structure; it does not fetch URLs, execute requests, or claim that each field value is semantically valid for a particular HTTP version or application.
About This Tool
HTTP headers carry metadata about requests and responses: content type, caching rules, validators, cookies, authentication schemes, redirects, accepted formats, and much more. Raw header blocks can be awkward to scan, especially when values contain punctuation or the same field name appears more than once. This parser turns pasted header lines into a structured table without making a network request.
How To Use It
- Paste a request or response header block. You may include a first start/status line such as HTTP/1.1 200 OK or GET / HTTP/1.1.
- Review any malformed-line messages. Valid field lines require a field name, a colon, and then a value (which may be empty).
- Use the parsed table to inspect the original field name, its value, and a lowercase normalized name useful for case-insensitive comparison.
- Repeated names are reported but kept as separate rows because repetition can be meaningful for some HTTP fields.
Examples
Response headers
Paste a status line followed by Content-Type, Cache-Control, ETag and other response fields to separate the metadata into readable rows.
Values containing colons
A Location value such as https://example.com/a:b is split only at the first colon, so colons inside the field value are preserved.
Repeated fields
Multiple Set-Cookie lines remain separate. The parser reports the repeated normalized name rather than incorrectly merging values that should not be combined blindly.
Useful Notes
HTTP field names are case-insensitive
HTTP field names are compared without case sensitivity. The parser preserves the spelling you pasted and also displays a lowercase normalized name, so Content-Type and content-type can be recognized as the same field name.
Why the parser does not blindly combine duplicates
Different HTTP fields have different combination rules. Some repeated field lines can be combined according to their field definition, while others such as Set-Cookie require special handling. The safest generic parser keeps repeated lines separate and tells you which normalized names repeat.
The first line is different from a header field
A raw message can begin with a request line or response status line. When the first non-empty line has no colon, this tool treats it as a start line instead of trying to interpret it as a header field.
Obsolete line folding is rejected
Older HTTP syntax allowed a field value to continue on a following line beginning with whitespace. That form is obsolete and can create ambiguous parsing behavior, so this tool reports such lines rather than silently joining them.
Structural parsing is not semantic validation
A field can have a valid name/value line structure while still containing a value that is inappropriate for that specific header, HTTP version, browser, server, proxy, or application. The tool deliberately does not claim to validate every registered or custom field grammar.
Local and non-executing
The pasted block is parsed in the browser. Hanakash does not need to contact the host named in a header, follow redirects, submit credentials, or execute a request to split the text into fields.
FAQ
Does this tool send the headers anywhere?
The parsing logic runs locally in the browser. The tool does not make a request based on the pasted header block.
Why are header names shown in lowercase too?
HTTP field names are case-insensitive. A lowercase normalized form makes comparisons and duplicate detection predictable while the original spelling is still preserved.
Why are duplicate fields not merged?
Generic merging can change meaning because field definitions have different combination rules and some fields need special handling. The parser preserves each line and reports repeated names instead.
Can I paste both request and response headers?
Yes. The parser focuses on field-line structure and can optionally separate a first non-header start/status line.
Does it validate Cache-Control, Content-Type or cookies in detail?
No. It parses their field names and values but does not implement every field-specific grammar. Use a specialized tool or protocol documentation when you need semantic validation of a particular field.
Related Tools
Cache-Control Header Builder
Build and understand HTTP Cache-Control directives.
URL Parser & Inspector
Inspect URL components and query parameters.
Query String Builder
Build encoded URL query strings from key-value parameters.
URL Encode / Decode
Convert URL text to and from percent encoding.