Network/HTTP
HTTP Headers Parser
Parse raw HTTP headers (from curl -I, DevTools, raw response) into a field list with descriptions and a security headers check.
Raw HTTP headers from curl -I or the Network tab in DevTools look like one solid block of text. This tool breaks it down into individual fields, explains what each header does, and flags common missing security headers.
How to use it
- Paste raw headers (curl -I output, the Headers tab in DevTools, or a copied raw response).
- Each header is parsed out individually with a short explanation of what it means.
- Missing security headers (Content-Security-Policy, X-Content-Type-Options, etc.) are flagged with a warning.
Common uses
- Quickly checking a site's security headers before a release or an audit.
- Understanding an unfamiliar header from a third-party API response without looking it up every time.
- Debugging caching or CORS issues by analyzing the server's response headers.
Things to keep in mind
Header order mostly doesn't matter for HTTP, except in rare cases involving repeated headers of the same type (e.g. multiple Set-Cookie headers).
A missing security header isn't always a mistake — some of them (HSTS, for example) only make sense for HTTPS sites or specific use cases.
Article about this tool: HTTP headers: what's hidden in every request and response
Frequently asked questions
What's the difference between request headers and response headers?
Request headers are sent by the client to describe what it's asking for (like Accept or Authorization), while response headers are sent by the server to describe what it's returning (like Content-Type or Cache-Control).
Why do some header names appear with different capitalization?
HTTP header names are case-insensitive by specification, so Content-Type and content-type are equivalent — different servers and tools just have different conventions for displaying them.
Does parsing headers here send them anywhere?
No. All parsing happens entirely in your browser — nothing is uploaded to a server.
Why can a single response include multiple Set-Cookie headers?
Each Set-Cookie header sets exactly one cookie, so if the server wants to set several, it adds several separate lines — unlike most headers, whose values can be safely joined with a comma.
Does the order of headers in an HTTP request or response matter?
Mostly no — HTTP doesn't guarantee or require a specific header order, except in rare cases where repeated headers of the same type matter specifically in the order they appear (like multiple Set-Cookie headers).