HTTP Request Header Analyzer
Inspect any request’s headers and understand what each one actually does — caching behaviour, content negotiation, authentication and the security signals that matter.
Paste a raw capture from your browser DevTools, a proxy (mitmproxy, Charles, Fiddler), an access log — or even a cURL command. The analyzer parses every field, explains it in plain English, groups the results into caching, content negotiation, authentication and security, and flags the patterns that quietly cause real problems: Basic auth in transit, Referer strings leaking query parameters, credentials over plain HTTP, outdated client signatures and duplicate or malformed headers.
Paste request headers
curl command.
Sensitive values stay masked until you reveal them. Analysis updates as you type.
Header reference
Every request header the analyzer knows about, with a plain-English explanation — searchable, so you can look one up without pasting a capture first.
How to read HTTP request headers
A request is a small negotiation between client and server, and the headers are where it happens. The request line says what (method + path); the headers say how. Four groups do most of the work:
Caching & conditional requests
Cache-Control tells intermediates what they may store and for how long (max-age=300 =
serve from cache for five minutes without asking). The If-* headers make requests
conditional: If-None-Match: "etag" or If-Modified-Since: <date> lets the
server answer 304 Not Modified with an empty body when nothing changed — the client keeps its
cached copy. That one round trip is how CDNs and browser caches save most of their bandwidth.
Content negotiation
Avoid the classic confusion: on a request, Accept is what the client wants back,
while Content-Type describes the body it is sending. Both use media types with optional
q= quality values (text/html;q=0.9 = second choice). Accept-Encoding: gzip, br
advertises which compressions the client can decode; Accept-Language picks the locale. The server
matches these against what it has and picks the best fit — or answers 406 Not Acceptable when
there is none.
Authentication schemes
Authorization: Bearer <token> is the modern default for APIs: the token is the credential,
and whoever holds it acts as you. Basic sends base64(username:password) on every request —
base64 is encoding, not encryption, so it is only acceptable over TLS (and even then it is fragile). API keys in
custom headers (X-Api-Key) are the same idea with a different name. Cookies carry session-based
authentication instead, which is why cookie flags and Origin/Referer matter for CSRF.
Security signals worth checking
- Referer leaks. Browsers send the full previous URL — including its query string — as the Referer. If your URLs carry tokens or personal identifiers, they go to every external site and API you touch.
- X-Forwarded-For is client-controllable. Anyone can set it. It is only meaningful when your own edge proxy appends the real client IP — otherwise treat it as a hint, never as identity.
- User-Agent is self-reported text. Useful for compatibility (and for spotting end-of-life browsers that are prime targets), useless as a security control.
- Credentials + plain HTTP. If
X-Forwarded-Protosayshttp(or the captured URL ishttp://) while auth headers are present, the credentials crossed the wire unencrypted.
Where to get headers for analysis: in Chrome/Edge/Firefox DevTools open the Network tab, click a request, and use Copy → Copy as cURL or read the Request Headers panel. mitmproxy, Charles and Fiddler show full captures on a proxy; server access logs (nginx, Apache) log selected request headers via their log format.
Suggested
