15 HTTP Headers That Leak Your Identity

Example:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/125.0.0.0 Safari/537.36

What it reveals: browser, engine, version, OS family, architecture. Combined with Accept-Language, this often identifies the exact build of your browser.

Mitigation: Chromium browsers are rolling out "User-Agent Reduction" which trims the version to major-only. Tor Browser ships a fixed UA shared by all users. Spoofing UA with an extension rarely works because other signals (Client Hints, TLS fingerprint) contradict the lie.

Example:

Accept-Language: en-GB,en;q=0.9,no;q=0.8,de;q=0.7

What it reveals: your preferred languages in order of preference, with quality weights. "en-GB, no, de" in that order narrows you down to maybe a few tens of thousands of people — probably a Norwegian who works in English and reads German. This header can defeat VPN-based location spoofing: your IP says California, but no says Norway.

Mitigation: browsers like Tor force en-US,en;q=0.5 for every user. In Firefox, set intl.accept_languages to a single common value like en-US, en.

Example:

sec-ch-ua: "Chromium";v="125", "Not.A/Brand";v="24", "Google Chrome";v="125"

What it reveals: browser brand and version, in structured form. Client Hints are the planned replacement for the User-Agent, so they're sent by all modern Chromium browsers. Unlike the UA string, they're much harder to spoof convincingly because the browser signs its own value.

Mitigation: Firefox doesn't send Client Hints by default. In Chromium you can disable specific high-entropy hints via the Permissions-Policy response header (if you control the server), but as a client you have no fine-grained control.

Example: sec-ch-ua-platform: "Windows"

What it reveals: your operating system family. Not unique, but rules out large swaths of the population. Harder to spoof than UA because it's a separate structured value.

Example: sec-ch-ua-mobile: ?0

What it reveals: boolean — mobile device or not. Only 1 bit of information, but helps a tracker pick the right fingerprinting strategy (mobile devices need a different approach).

Example: Accept-Encoding: gzip, deflate, br, zstd

What it reveals: compression algorithms your browser supports. The exact ordering and inclusion of newer formats (like zstd) is version-specific and contributes to browser fingerprinting.

Example: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

What it reveals: which MIME types your browser will accept and at what priority. The order and quality weights are slightly different across browsers and versions — enough to distinguish Firefox 124 from Firefox 125 in some cases.

Example: Referer: https://www.google.com/search?q=how+to+stop+webrtc+leaks

What it reveals: the URL you came from — often including a search query or session token. This is arguably the single most revealing header when not stripped, because it can expose behavioural patterns (what you were just reading before clicking) and sometimes session data in URL parameters.

Mitigation: modern browsers default to Referrer-Policy: strict-origin-when-cross-origin, which strips the path and query when the request crosses origins. Sites can weaken this. You can't override it client-side, but extensions like uBlock Origin can strip it entirely.

What it reveals: everything the site has previously stored about you — session IDs, user IDs, ad-tracker IDs. Cookies are the original tracking mechanism and still the most precise one.

Mitigation: block third-party cookies (default in Safari and Firefox), use a separate container/profile for sensitive browsing, clear cookies regularly for advertising domains.

What they reveal: your opt-out preference. DNT: 1 (Do Not Track) is almost universally ignored; Sec-GPC: 1 (Global Privacy Control) is legally binding in some US states under CCPA.

Privacy twist: sending a rare privacy signal can increase your fingerprintability because few users enable it. Brave and DuckDuckGo browsers send Sec-GPC: 1 by default, so it's no longer distinctive on those.

Example:

sec-fetch-site: same-origin
sec-fetch-mode: navigate
sec-fetch-dest: document
sec-fetch-user: ?1

What they reveal: security metadata added by the browser — whether the request came from user action, what it's for, and the relationship between origins. These are defensive (help servers detect CSRF) rather than identifying, but their exact presence/absence differs by browser.

What it reveals: the scheme + host + port of the page that initiated the request. Usually not a privacy concern, but on cross-origin requests it confirms what site you were on.

Example: X-Forwarded-For: 203.0.113.42, 10.0.0.5

What it reveals: the chain of IPs that handled the request before it reached the server. Set by proxies, CDNs, and corporate gateways. A VPN or CGNAT provider may leave your real IP in this chain if misconfigured.

Where to check: this header is added by infrastructure, not sent by your browser. To see what the destination server sees, use the HTTP Headers Inspector.

Example:

x-vercel-ip-country: NO
x-vercel-ip-city: Oslo
x-vercel-ip-timezone: Europe/Oslo
cf-ipcountry: NO

What they reveal: geolocation derived from your IP by the CDN. These headers aren't sent by you — they're added server-side by Vercel, Cloudflare, and similar providers. The destination app gets your approximate city and timezone for free without any IP database.

Mitigation: VPN routes you through a different exit IP, so the CDN geo-lookup returns the VPN's location instead of yours.

Example: Upgrade-Insecure-Requests: 1

What it reveals: preference for HTTPS over HTTP. Nearly every modern browser sends 1. Absence of this header is itself an unusual signal.