HTTP Header Inspector

Your request headers

HTTP Header Inspector

Every HTTP request your browser makes carries a set of headers — small key/value fields the client sends alongside the URL it's asking for, describing itself and what it can accept. Some are set automatically by the browser (User-Agent, Accept, Accept-Encoding), some reflect explicit privacy choices you made (Do Not Track), and some are added or rewritten by whatever sits between you and the destination server — a corporate proxy, a VPN client, a CDN, or (in our own case) the nginx front sitting in front of this very API. Reading exactly what arrived, unfiltered, is the only way to know for certain what a server actually sees — browser devtools show what your browser SENT, not necessarily what survived every hop in between.

This tool reads the incoming request's headers for THIS exact request — nothing is fetched, cached, or stored; every reload gives you a fresh, live answer that can differ from the last one if you change a browser setting, switch networks, or a proxy in the path rewrites something. On top of the raw list, a few of the most informative headers are parsed into a friendlier shape: Accept-Language is split into individual language tags with their quality weights, sorted by preference; the Sec-CH-UA family of "client hints" (a newer, more privacy-conscious replacement for parsing the User-Agent string) is broken out into browser brand/version, platform and whether the device identifies as mobile; and Accept-Encoding is split into the list of compression schemes your client is willing to accept.

One category deserves its own explanation: X-Forwarded-For, Via and X-Real-IP. If any of these appear, don't read it as "my browser is leaking my real IP" — these are proxy-chain headers, and in production the very first hop your request makes is our own nginx front sitting in front of this API server, which adds exactly this kind of header as a normal, expected part of how a reverse proxy works. Their presence tells you something passed through at least one intermediary; it does not by itself tell you whether that intermediary is your own browser, your ISP, a corporate network, or simply our own infrastructure relaying your request internally.

For safety, a fixed set of headers never appears in the response no matter what arrives on the request: Cookie, Authorization, Proxy-Authorization, X-Api-Key, and — as a doubly-safe backstop — any header whose name contains "token", "secret" or "key", case-insensitively. These are withheld entirely, not replaced with a placeholder like "[redacted]", because even confirming a credential header's PRESENCE can be useful information to an attacker; the goal is a tool safe enough to screenshot into a support ticket without a second thought. Every value is also always rendered as inert text, never executed as markup — a header carrying HTML or script-like bytes is shown exactly as received, harmlessly, as data.

How to read this page

1. Load this page

   As soon as the page loads, it calls our own /api/v1/tools/headers endpoint with a normal browser request — no button to click, no input to fill in.

2. Review the raw header list

   The table shows every header that arrived, in the exact form the server received it, minus the handful of credential-bearing headers withheld by design.

3. Check the parsed highlights

   Accept-Language, Do Not Track, Sec-CH-UA client hints, Accept-Encoding and any proxy headers are broken out and explained individually below the raw table.

4. Reload to see it change

   Switch a browser setting, a network or a VPN and reload — the result reflects exactly the new request, with nothing cached from before.

Glossary

HTTP request header

A key/value field sent by the client as part of an HTTP request, describing the request itself or the client sending it — as opposed to a response header, which the server sends back.

User-Agent

A header identifying the requesting browser/client, its rendering engine and often its OS — historically the main way servers detected browser capabilities, now increasingly supplemented (or replaced) by client hints.

Accept-Language

A header listing the languages the client prefers, each optionally weighted with a quality value (q) from 0 to 1 — servers use it to pick a response language when one isn't explicitly requested.

Client hints (Sec-CH-UA)

A newer family of structured request headers (Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile) that expose specific, opt-in browser/device facts without parsing a free-text User-Agent string — designed to be less fingerprintable than the string it's replacing.

Do Not Track (DNT)

A header a browser can send to signal the user doesn't want to be tracked across sites — a request, not an enforcement mechanism; servers and third parties aren't technically required to honor it.

Proxy header (X-Forwarded-For / Via / X-Real-IP)

Headers added by intermediaries (reverse proxies, load balancers, CDNs) to record the original client address or the chain of hops a request passed through — not something a browser sends on its own.

API equivalent

This page calls our own public tools endpoint under the hood — you can call the same endpoint directly, unauthenticated, subject to a per-caller rate limit. The response depends entirely on the headers YOUR client sends with the request, so a plain curl call (which sends far fewer headers than a browser) looks different from what this page shows:

curl "https://ip.xakki.pro/api/v1/tools/headers"

Example response (from a plain curl call):

{
  "headers": {
    "Accept": "*/*",
    "Accept-Encoding": "gzip",
    "User-Agent": "curl/8.5.0"
  },
  "parsed": {
    "userAgent": {"raw": "curl/8.5.0"},
    "acceptLanguage": [],
    "doNotTrack": false,
    "clientHints": {"mobile": false},
    "acceptEncoding": ["gzip"],
    "proxyHeaders": {"present": false}
  }
}

Read the full API docs

Related tools

• All free tools
• WebRTC Leak Test
• DNS & PTR Lookup
• IP Reputation Check

Frequently asked questions

Why don't I see a Cookie or Authorization value here, even though I'm logged in?

By design — those headers (Cookie, Authorization, Proxy-Authorization, X-Api-Key, and anything with "token"/"secret"/"key" in its name) are withheld unconditionally before the response is built, whether or not they were actually sent. This tool's whole point is to be safe to share a screenshot of.

Why do I see X-Forwarded-For or Via even though I didn't set them?

You almost certainly didn't — these are typically added by the network path itself, not by your browser. In production, our own nginx front is the very first hop and adds exactly this kind of header as standard reverse-proxy behavior; a corporate network, VPN or CDN in the path can do the same.

Does reloading the page always show the same headers?

Mostly, but not necessarily — this tool reads the live request headers of the CURRENT reload, with no caching. Changing a browser setting, switching networks, or a proxy path change between reloads can all change what arrives, and you'd see the difference immediately.

What's the difference between the Accept-Language shown here and my browser's actual language settings?

This shows exactly the header value your browser sent — which usually, but not always, directly reflects your OS/browser language preference list. Some browsers and privacy extensions deliberately simplify or override it to reduce how uniquely identifying it is.

Can this tool show me a URL's response headers, not just my own request headers?

No — this endpoint only ever reads the request that hit it; it never fetches another URL on your behalf. Inspecting an arbitrary URL's response headers is a different capability (an outbound fetch) that this free tool deliberately does not implement.