What is an HTTP header parser?

An HTTP header parser takes raw HTTP header text — the kind you see in browser DevTools, curl output, or Postman — and breaks it into structured fields: the header name, its value, and an explanation of what that header does. This tool parses both request headers (sent by the client) and response headers (sent by the server).

How do I get raw HTTP headers to paste here?

In Chrome or Firefox DevTools, open the Network tab, click any request, and copy the text from the 'Headers' tab. In curl, use 'curl -I https://example.com' to see response headers, or 'curl -v https://example.com' for both request and response headers. In Postman, the raw headers are shown in the request and response sections.

What are the different HTTP header categories?

HTTP headers are grouped by their purpose: Request headers are sent by the client (Accept, User-Agent, Cookie); Response headers are sent by the server (Location, Server, Set-Cookie); Representation headers describe the message body (Content-Type, Content-Encoding, Content-Length); Caching headers control how responses are cached (Cache-Control, ETag, Expires); Security headers protect against web attacks (Content-Security-Policy, Strict-Transport-Security); CORS headers control cross-origin resource sharing; Auth headers handle authentication (Authorization, WWW-Authenticate).

What is the difference between request and response headers?

Request headers are sent by the browser or HTTP client to the server — they describe what the client wants, what it can accept, and provide authentication (examples: Host, Accept, Authorization, Cookie, User-Agent). Response headers are sent back by the server — they describe the response body, caching instructions, and security policies (examples: Content-Type, Cache-Control, Set-Cookie, Strict-Transport-Security).

Is my header data sent to a server?

No. All parsing and description lookups happen entirely in your browser using JavaScript. No header data is transmitted to any server. Your HTTP headers — which may contain sensitive values like cookies or authorization tokens — stay completely private.

HTTP Header Parser Online — Parse & Explain HTTP Headers

You’re debugging a caching issue. The CDN is serving stale content even though you deployed 10 minutes ago. You open DevTools, copy the response headers, and stare at 15 key-value pairs: Cache-Control, ETag, Vary, X-Cache, CF-Cache-Status, Age… You know one of these is wrong, but you can’t remember whether max-age=0 means “don’t cache” or “always revalidate,” and what Vary: Accept-Encoding actually affects.

Why This Parser (Not the HTTP Request Builder)

PureDevTools has an HTTP Request Builder for constructing HTTP requests and generating code snippets. This tool parses existing headers — paste raw headers from DevTools, curl, or Postman and get a structured table with each header’s name, value, category, and a plain-English explanation. It covers 50+ common headers across caching, security, CORS, content negotiation, and authentication. Everything runs in your browser; no data is sent anywhere.

What Are HTTP Headers?

HTTP headers are key-value pairs exchanged between a client (browser, curl, API client) and a server as part of every HTTP request and response. They carry metadata about the message: what content type the body contains, how long it should be cached, what security policies apply, whether the request is authenticated, and much more. Understanding HTTP headers is essential for debugging APIs, optimizing web performance, and hardening application security.

This tool takes raw HTTP header text — copied from browser DevTools, curl, Postman, or any HTTP client — and parses it into a structured table that shows each header’s name, value, category, and a plain-English explanation.

How to Get Raw HTTP Headers

Browser DevTools (Chrome, Firefox, Edge):

Open DevTools with F12 or Ctrl+Shift+I
Navigate to the Network tab
Click any request in the list
Select the Headers tab
Copy the text under “Request Headers” or “Response Headers”

curl:

# Show only response headers
curl -I https://example.com

# Show both request and response headers (verbose)
curl -v https://example.com 2>&1 | grep "^[<>]"

Postman: The “Headers” tab under each request and response shows all headers in a copyable format.

Node.js / fetch: Log response.headers to inspect response headers programmatically.

HTTP Header Categories

Request Headers

Request headers are sent by the client to provide context about the request and the requester’s capabilities:

Header	Purpose
`Host`	The target server hostname — required in HTTP/1.1
`Accept`	MIME types the client can process (e.g., `text/html`, `application/json`)
`Accept-Encoding`	Compression algorithms the client supports (gzip, br, deflate)
`Authorization`	Credentials for authenticating the request (Bearer token, Basic auth)
`Cookie`	Cookies previously set by the server
`User-Agent`	Browser or client software identification
`Referer`	The URL of the page that linked to the current request
`Origin`	The origin of a cross-origin request (used in CORS)

Response Headers

Response headers are sent by the server to describe the response and instruct the client:

Header	Purpose
`Content-Type`	MIME type of the response body (e.g., `application/json; charset=UTF-8`)
`Content-Length`	Size of the response body in bytes
`Location`	URL for a redirect (used with 3xx status codes)
`Set-Cookie`	Instructs the browser to store a cookie
`Server`	Software running on the server (often partially redacted for security)
`WWW-Authenticate`	Authentication challenge sent with a 401 Unauthorized response

Caching Headers

Caching headers control how responses are stored and reused by browsers and intermediate caches:

Header	Purpose
`Cache-Control`	Primary caching directive — controls max age, public/private, no-store
`ETag`	Unique version identifier for a resource — used for conditional requests
`Last-Modified`	Date the resource was last changed — used with `If-Modified-Since`
`Expires`	Date after which the response is considered stale
`Vary`	Lists request headers that affect the cached response
`Age`	Time in seconds the object has been in a proxy cache

Security Headers

Security headers protect users against common web attacks. Every production web application should include these:

Content-Security-Policy (CSP) The most powerful security header — defines trusted sources for scripts, styles, images, fonts, frames, and other resources. A well-configured CSP is the primary defense against XSS (cross-site scripting) attacks.

Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' 'unsafe-inline'

Strict-Transport-Security (HSTS) Forces browsers to use HTTPS for all subsequent visits. Once set, browsers will refuse to load the site over HTTP. The includeSubDomains directive extends protection to all subdomains; preload requests inclusion in browser preload lists.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

X-Frame-Options Prevents your pages from being embedded in <iframe> elements on other sites — a defense against clickjacking attacks. SAMEORIGIN allows embedding only from the same origin; DENY blocks it entirely.

X-Content-Type-Options: nosniff Prevents browsers from MIME-sniffing a response away from the declared Content-Type. This stops browsers from interpreting a CSS file as JavaScript, for example.

Referrer-Policy Controls how much of the referring URL is included in the Referer header. strict-origin-when-cross-origin is the recommended default — it sends the full URL for same-origin requests but only the origin for cross-origin requests, and nothing over HTTP.

CORS Headers

Cross-Origin Resource Sharing (CORS) headers allow browsers to make cross-origin requests from JavaScript. Without these headers, the browser’s same-origin policy blocks cross-origin API calls.

Preflight requests: Before a cross-origin request with certain methods or headers, the browser sends an OPTIONS preflight request to check whether the actual request is permitted. The server responds with CORS headers describing what is allowed.

Header	Direction	Purpose
`Origin`	Request	The origin making the request
`Access-Control-Allow-Origin`	Response	Which origins are allowed (`*` or a specific origin)
`Access-Control-Allow-Methods`	Response	HTTP methods allowed for cross-origin requests
`Access-Control-Allow-Headers`	Response	Request headers the client is allowed to include
`Access-Control-Allow-Credentials`	Response	Whether cookies can be included (must be `true` to allow cookies)
`Access-Control-Max-Age`	Response	How long the preflight result can be cached

Common Debugging Scenarios

CORS errors: Look for Access-Control-Allow-Origin in the response headers. If it’s missing or doesn’t match your request’s Origin, the browser will block the response. The Access-Control-Allow-Methods and Access-Control-Allow-Headers headers must also permit the method and headers you’re using.

Caching issues: Check Cache-Control, ETag, and Last-Modified. A Cache-Control: no-store response will never be cached. If you’re seeing stale content, check if Vary: Cookie is causing separate caches per cookie value.

Authentication failures: The WWW-Authenticate header in a 401 response tells you exactly what authentication scheme the server expects. Authorization: Bearer <token> is used for JWT-based APIs; Authorization: Basic <base64> is used for HTTP Basic auth.

Redirect loops: Check the Location header in 301/302 responses to see where requests are being sent. A misconfigured redirect (e.g., HTTPS redirects back to HTTP) is easy to spot by tracing the Location chain.

Slow responses: Content-Encoding: gzip or br indicates compression is enabled. Transfer-Encoding: chunked means the server is streaming the response. Absence of Content-Length may indicate chunked transfer or streaming.

Fetch Metadata Request Headers

Modern browsers send a set of Sec-Fetch-* headers with every request, providing the server with structured information about the request’s context without relying on the (spoofable) Referer header:

Header	Values	Meaning
`Sec-Fetch-Dest`	`document`, `image`, `script`, `worker`, …	What resource type is being fetched
`Sec-Fetch-Mode`	`navigate`, `cors`, `no-cors`, `same-origin`	How the request was initiated
`Sec-Fetch-Site`	`same-origin`, `same-site`, `cross-site`, `none`	Relationship to the initiator’s origin
`Sec-Fetch-User`	`?1`	Whether user interaction triggered the navigation

Servers can use these headers to implement resource isolation policies — for example, rejecting document navigations to API endpoints.

Client Hints

User-Agent Client Hints (Sec-CH-UA-*) are a privacy-preserving replacement for the User-Agent string. Instead of sending a detailed user agent string with every request, browsers send minimal information by default:

Sec-CH-UA: Brand and significant version (e.g., "Chromium";v="122")
Sec-CH-UA-Mobile: ?1 for mobile devices, ?0 for desktop
Sec-CH-UA-Platform: Operating system name (e.g., "Windows", "macOS")

Servers can request additional client hint information via the Accept-CH response header.

Frequently Asked Questions

What is the difference between HTTP/1.1 and HTTP/2 headers? The header names and values are the same across HTTP versions, but the wire format differs. HTTP/1.1 sends headers as plain text, one per line. HTTP/2 uses HPACK binary compression to reduce header size. HTTP/2 also introduced pseudo-headers (:method, :path, :scheme, :status) that carry request-line and status-line information in header format. This tool parses the human-readable representation produced by DevTools and curl, which normalizes both formats.

Why does the Referer header have a spelling mistake? The Referer header has been misspelled since 1996, when Phillip Hallam-Baker submitted the original HTTP spec. The correct spelling is “referrer” but the misspelling was included in RFC 1945 and has been preserved for backwards compatibility ever since. The Referrer-Policy header (introduced later) uses the correct spelling.

What is an ETag and how does it work? An ETag (entity tag) is an opaque identifier assigned by the server to a specific version of a resource. When a client requests a resource it already has cached, it includes the stored ETag in an If-None-Match request header. If the resource hasn’t changed, the server returns 304 Not Modified with no body — saving bandwidth. If it has changed, the server returns 200 OK with the new content and a new ETag.

Is my header data private? Yes. All parsing happens entirely in your browser using JavaScript. No header data is transmitted to any server. Your headers may contain sensitive values like Authorization tokens or Cookie values — none of this leaves your device.

HTTP Header Parser