HTTP Header Parser

Parse and diagnose HTTP headers and routing signals in your browser. No input is sent to a server. Use it for first-pass observation-gap troubleshooting.

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste headers and click “Parse”. It lists name: value pairs.

Notes (this tool)

  • Empty or invalid lines are ignored.

About this page

What does this tool do?

Parse HTTP request/response headers and list header names and values.

Useful for multi-line inputs and repeated headers (e.g., Set-Cookie).

Paste output from browser DevTools or curl to troubleshoot misconfigurations (cache, cookies, CORS, etc.).

Typical use cases

  • Inspect Cache-Control/ETag/Last-Modified
  • Check Set-Cookie attributes (Secure/SameSite/HttpOnly)
  • Inspect CORS headers (Access-Control-*)
  • Check Content-Type/Content-Encoding

Cookie is a request header; Set-Cookie is a response header. Set-Cookie often repeats and includes important attributes (SameSite/Secure/HttpOnly).

Cache-Control basics

  • no-store: do not store (for sensitive data)
  • no-cache: must revalidate (often with ETag)
  • max-age: cache lifetime in seconds

What this tool does

  • Parse headers (name: value)
  • Keep duplicate headers
  • Inspect Cookie/Set-Cookie

Debugging workflow (recommended)

  • Paste actual headers or observed values
  • Compare expected and observed values
  • Trace proxy, CDN, and redirect paths

Operational notes

  • Intermediaries may rewrite headers. Compare captures from equivalent points.
  • Confirm final decisions with server logs and configuration such as trusted proxy and routing.

Referenced specs

  • RFC 9110 (HTTP Semantics)
  • RFC 6265 (HTTP Cookies)

FAQ

Can I mix request and response headers?

Lines are parsed independently, so mixed headers can be listed, but interpretation depends on context.

Why are there repeated headers?

Some headers can repeat (like Set-Cookie). Proxies/middleware can also add headers.

References

  1. RFC 9110 (HTTP Semantics)
  2. RFC 6265 (HTTP Cookies)

These links are generated from site_map rules in recommended diagnostic order.

  1. Response Headers Parser — Parse response headers into structured data
  2. Content-Type Inspect — Parse Content-Type and inspect MIME/charset
  3. Retry-After Inspect — Parse Retry-After and inspect retry wait behavior
  4. Server-Timing Inspect — Parse Server-Timing and inspect latency metrics
  5. Link Header Inspect — Parse Link headers and inspect rel/as/type
  6. X-Content-Type-Options Inspect — Parse X-Content-Type-Options and validate nosniff
  7. How to Diagnose Retry Storms on 429/503 — Isolate Retry-After parsing and client implementation gaps to stop excessive retries
  8. How to choose response header tools — Map Retry-After, Server-Timing, Link, Content-Type, and nosniff checks by symptom

Response Header Diagnostics

Step through raw headers to inspect Retry-After, Server-Timing, Link, and Content-Type

Example

Content-Type: application/json
Cache-Control: no-store
Set-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax