Two layers of exposure
It helps to split this into two categories, because they behave completely differently.
- Automatic, protocol-level exposure — everything your browser hands over on every single request, whether or not the site's code ever asks for it. This happens at the network and protocol level, before the page has rendered a thing, and you can't opt out of it without breaking how the web works.
- JavaScript-readable exposure — everything a script running on the page can additionally pull, but only if it bothers to ask, using APIs built into the browser. This is where almost all of the genuinely invasive tracking techniques live.
The headers sent with every request
Every request your browser makes carries a set of HTTP headers describing itself. Most are harmless plumbing; a few are worth knowing by name because of what they actually reveal.
User-Agent
This header used to be a detailed string naming your exact browser version, operating system build, and rendering engine. Chrome has been deliberately freezing and trimming it since 2023 in favor of User-Agent Client Hints, a system where the detailed version data is only sent if a site specifically requests it, rather than broadcast to everyone by default. It's a genuine, if quiet, privacy improvement most people never noticed happening.
Accept-Language and Referer
Accept-Language tells the site your preferred language and region, which is how a site shows you Spanish content before you've clicked anything. Referer tells the site which page you arrived from, and it used to leak the full previous URL, including anything sensitive in that URL's query string. Modern browsers now default to a stricter Referrer-Policy that trims it down to just the origin domain when you're navigating across different sites, which closed off a surprisingly common accidental data leak.
Do Not Track and Global Privacy Control
DNT, or Do Not Track, is the header that's supposed to say "please don't track me," and sites have been legally free to ignore it for over a decade — most do. Its successor, Global Privacy Control (GPC), is a similar signal, but with actual legal weight behind it in places like California and Colorado, where certain businesses are required by state privacy law to honor it as an opt-out request. It's the rare case of a browser header a site can be held accountable for ignoring, depending on where you and the site both are.
Your IP address and your TLS fingerprint
Your IP address is the most obvious thing exposed, since the site needs it to send data back to you at all — it's not optional at the protocol level, and it's how a site gets a rough read on your location and internet provider without asking your browser for anything. A VPN is the standard fix for this specific layer, though it does nothing for the fingerprinting layer covered below.
Less well known is that the encrypted connection itself carries a fingerprint before any HTTP headers are exchanged. When your browser opens an HTTPS connection, it sends a TLS "ClientHello" message listing which encryption methods it supports and in what order. Different browsers, and even different versions of the same browser, construct this list slightly differently — and that specific ordering and combination, commonly hashed into what's called a JA3 or JA4 fingerprint, can identify what software is actually making the request even if the User-Agent header lies about it. It's one of the main techniques bot-detection services use to catch scripts pretending to be a normal browser, and it happens entirely below the level a website's own JavaScript can see or control.
What JavaScript can additionally read
This is the layer that only activates if a script on the page goes looking, and it's considerably larger than most people expect.
Device and screen details
A page can read your screen resolution and color depth, your timezone, the number of CPU cores your device reports (navigator.hardwareConcurrency), and, on some browsers, an estimate of your device's memory. None of these alone is unusual, but together they start narrowing down which device you're likely using.
Rendering-based fingerprints
A page can enumerate which fonts you have installed by measuring how text renders in different typefaces. It can draw an invisible image using the canvas API and hash the exact pixel output, which varies slightly by GPU, driver, and font rendering — a technique that produces a near-unique signature without ever asking your permission, because rendering a canvas doesn't look like anything worth a permission prompt. A similar trick works through AudioContext, generating an inaudible sound wave and measuring tiny differences in how your specific hardware processes it.
The battery API that got removed
One data point worth knowing is now gone: the Battery Status API used to let any page check your device's exact battery percentage and charging state, ostensibly to let sites save power on low battery. Researchers showed it could be used to fingerprint and even track individual devices across sessions, and both Firefox and Chrome quietly removed general access to it between 2016 and 2019. It's a useful example that this fight goes both ways — not every fingerprinting surface that exists today will still exist in a few years.
The WebRTC exception
Worth calling out on its own because it doesn't fit either category cleanly: WebRTC, the browser technology behind video calls and voice chat, can reveal your real local network IP address and, in some misconfigurations, your public IP even when you're behind a VPN — a request that bypasses the normal browser sandbox because it's designed to set up a direct peer-to-peer connection. We cover the mechanics of exactly how that leak happens in a separate guide, and you can check whether your own setup is affected with our WebRTC leak test.
Why none of this needs to be unique on its own
No single signal here identifies you. Plenty of people share your timezone, your screen resolution, and your language setting. The reason fingerprinting works isn't any one data point, it's the combination.
In 2010, EFF researcher Peter Eckersley ran this exact test at scale, collecting roughly 470,000 browser fingerprints through the original Panopticlick project. 83.6% of them turned out to be unique among the entire sample, just from combining ordinary-looking signals like fonts, plugins, and screen size — none of which, alone, would raise any privacy concern. The project's modern successor, Cover Your Tracks, still measures this the same way, in "bits of identifying information": each additional signal narrows the crowd you blend into, and it doesn't take many before that crowd is just you.
What's actually worth changing
You can't turn off the HTTP headers or the TLS handshake without breaking the web for yourself, and that's fine — that layer was never the invasive one. The JavaScript-accessible layer is where blocking actually helps: a tracker-blocking extension that prevents fingerprinting scripts from running at all is more effective than trying to spoof individual values, since a spoofed value that looks slightly unnatural (a font list that doesn't match your claimed operating system, for instance) can itself become a new way to stand out. Firefox and Safari both ship some fingerprinting resistance by default now; Chrome, as of 2026, still leans more on extensions to fill that gap. If you want to see exactly which of the signals above your own browser is currently exposing, our browser fingerprint test shows the live values, not just the theory.
Frequently asked questions
Can a website see everything about my computer just by me visiting it?
Not everything, but more than most people expect. A visit alone hands over your IP address, language, and a TLS-level fingerprint automatically. The device-level details — fonts, GPU, screen size, and so on — require the page to run JavaScript that specifically asks for them, which almost every commercial site does through analytics and advertising code.
Does incognito or private browsing stop any of this?
No. Private browsing controls what gets saved to your device afterward, not what's transmitted during the session. Every signal described here, including the TLS and JavaScript-readable ones, works identically in a private window — see our incognito mode guide for the full breakdown of what it does and doesn't cover.
What's the difference between the User-Agent header and a canvas fingerprint?
Two different mechanisms entirely:
- User-Agent is a text string your browser sends voluntarily, and it can be spoofed or blocked outright with an extension.
- Canvas fingerprint is a measurement, generated by actually rendering something and reading back tiny hardware-level differences in the result. It's harder to fake convincingly, because faking it means predicting exactly what your specific GPU and font-rendering stack would have produced naturally.
Is there any way to send fewer of these signals without breaking websites?
Blocking third-party scripts with a tracker blocker removes most fingerprinting attempts without breaking the site you're actually on, since the fingerprinting code is usually loaded from an ad or analytics domain, not the site's own code. Browsers with built-in fingerprint resistance (Firefox's, in particular) also normalize some of these values across all users on purpose, so you blend into a larger crowd instead of standing out.
Sources
- RFC 9110 — HTTP Semantics, including standard request headers
- EFF Cover Your Tracks — methodology and the original Panopticlick fingerprint study
- W3C — User-Agent Client Hints specification
- MDN — RTCPeerConnection and WebRTC's network access model
Written by PrivacyTestLab
The header and API behavior described here is checked against current browser vendor documentation and the relevant W3C and IETF specifications rather than repeated from older explainers written before Client Hints and stricter Referrer-Policy defaults shipped.
