Browser fingerprinting identifies you by combining dozens of properties your browser reveals to every page: screen size, installed fonts, GPU model, time zone, language and how your machine draws a hidden canvas image. Hashed together they form an identifier that needs no cookie, survives private mode and is unique for most desktop users.
What a fingerprint is made of
A cookie is an identifier a site gives you. A fingerprint is an identifier a site derives from you. The page runs a script that reads properties through ordinary web APIs, or a server reads them from request headers, then feeds the values into a hash function. The result is a short string such as a91f3c0e. Visit again tomorrow from the same laptop and the same string comes out, whether or not you cleared cookies.
No single property identifies you. Your time zone narrows the world to a few hundred million people; your screen resolution narrows it further; the exact list of fonts installed on your machine narrows it dramatically. The combination is what identifies. This is why fingerprinting is discussed in terms of entropy: each signal contributes some bits of identifying information, and the bits add up.
The signals that matter most
| Signal | How it is read | Why it identifies |
|---|---|---|
| Canvas rendering | Draw text and shapes on a hidden <canvas>, export the pixels | Anti-aliasing and sub-pixel output differ by GPU, driver, OS and font stack |
| WebGL renderer | WEBGL_debug_renderer_info plus rendering tests | Exposes the GPU model and driver; combined with a canvas hash it is very stable |
| Fonts | Measure text width for hundreds of font names | Installed font lists vary with every application you have ever added |
| AudioContext | Generate a signal offline and hash the output buffer | Floating-point differences in the audio stack |
| Screen and window | screen.width, colour depth, device pixel ratio, viewport size | Moderately common values, but combined with the rest they help |
| Hardware hints | navigator.hardwareConcurrency, deviceMemory, touch points | Core count and memory bucket separate machine classes |
| User-Agent and Client Hints | Request headers and navigator.userAgentData | Browser, version and platform; Chrome now reduces the string but offers hints on request |
| Language and time zone | navigator.languages, Intl.DateTimeFormat | Low entropy alone, but they anchor the rest to a region |
The first four rows are the important ones. Screen size and language are configuration; canvas, WebGL, fonts and audio are consequences of hardware and drivers, which you do not change from one day to the next. That stability is what makes a fingerprint useful as a tracking key. Our browser check reports the canvas and WebGL parts separately, as canvas fingerprinting exposure and WebGL renderer exposure, because they are the two most worth doing something about.
How uniqueness is measured
The standard way to express a fingerprint's strength is in bits of identifying information. If a property has a value shared by one person in two, it carries one bit. One in four, two bits. One in a thousand, about ten bits. Because there are roughly eight billion people online, about 33 bits are enough to single out one individual, and in practice you need fewer because a tracker only has to distinguish you from the other visitors to its client sites, not from everyone alive.
This framing comes from the EFF's Panopticlick project, now called Cover Your Tracks. Its 2010 study, How Unique Is Your Web Browser?, found that 83.6 percent of the browsers in its sample had a fingerprint that was unique in the dataset, rising to 94.2 percent when Flash or Java was installed. Plugins are gone, but canvas and WebGL took their place, and desktop browsers with a normal set of fonts remain overwhelmingly unique.
A worked example makes the arithmetic concrete. Suppose a tracker records the following for one visitor:
timezone: Europe/Berlin
languages: de-DE,de,en-US,en
screen: 2560x1440 @ 2x, 24-bit
hardwareConcurrency: 8
platform: macOS (from Client Hints)
fonts (hash): 3c7e91b0
canvas (hash): f04d1a6e
webgl renderer: Apple M2
audio (hash): 77b2e5c9
Each row alone matches thousands or millions of people. The combination matches very few, and on a data set of a tracker's size it may match exactly one. When we report fingerprint uniqueness, we are estimating how many bits that combination carries against the browsers we have seen, which is why the number changes as the population changes.
Where fingerprinting is used
Fingerprinting has two very different customers, and it helps to keep them apart.
- Fraud and bot detection. Banks, ticket sellers and login pages fingerprint to notice when a session that looks like you suddenly comes from a different machine. This is the legitimate case, and it is why browsers do not simply switch every API off.
- Cross-site tracking. Advertising and analytics scripts fingerprint to recover an identifier after third-party cookies are blocked, deleted or partitioned. This is the case privacy law and browser vendors have been squeezing, and it is the reason tracking moved from cookies to fingerprints in the first place.
The technique is identical; only the purpose differs, and the page cannot be trusted to tell you which one it is doing. That is why protections have to be applied at the browser level rather than site by site.
Why hand-spoofing makes things worse
The most common mistake is to install an extension that changes one value, such as the User-Agent, or to randomise the canvas output with a plug-in. This usually increases your entropy. A browser that says it is Chrome on Windows but has Safari's font list, an Apple GPU and a macOS time-zone quirk is now the only browser on the internet with that combination. Fingerprinting scripts explicitly check for these inconsistencies, and a mismatch is itself a strong signal.
The defences that work are the ones designed as a whole. Tor Browser makes every user present the same values: the same window size buckets, the same font list, the same reported hardware. Firefox's privacy.resistFingerprinting setting is the same code, and its Enhanced Tracking Protection in strict mode adds fingerprinting protection that subtly and consistently perturbs canvas and a few other APIs so that the value is stable within a session but not tied to your hardware. Brave randomises in a per-site, per-session way it calls farbling, so each site sees a different but internally consistent browser. Safari limits the font list to the system set, refuses the WebGL debug renderer extension by default and, since Safari 17, offers an advanced tracking and fingerprinting protection setting that can apply to all browsing rather than only private windows.
Chrome takes a different position. It has reduced the User-Agent string to a frozen, low-entropy form and moved the detail into User-Agent Client Hints that a site must ask for, which we report as Client Hints exposure. Beyond that, Chrome does not ship fingerprinting resistance as a user setting, on the argument that it would break too many sites. That is a defensible engineering position, and it means Chrome users who care about fingerprinting are relying on extensions and on reducing what scripts can run at all.
What actually reduces your fingerprint
- Pick a browser that ships coherent protection. Firefox with Enhanced Tracking Protection set to strict, Safari with advanced protection on for all browsing, Brave, or Tor Browser when you need to be indistinguishable. Our guide to the browser settings that matter shows where each toggle lives.
- Block the scripts that fingerprint. Most commercial fingerprinting is done by a handful of tracking libraries loaded from third-party domains. A content blocker with a tracking list stops them before they run, which removes the question entirely for those sites.
- Do not customise the things scripts can see. A default window size, default zoom, default fonts and a common language list all reduce entropy. This is the least satisfying advice, and it is also the most effective.
- Stop thinking of private mode as protection. A private window has the same hardware, the same fonts and the same GPU. Our guide on what private browsing does and does not hide covers this in detail.
- Measure, do not guess. Run the browser check, note the uniqueness estimate, change one thing, run it again. The difference between settings is often smaller than people expect, and occasionally the opposite of what they expect.
The limits of any defence
It is worth being honest about what is achievable. If you log in to a site, it knows who you are regardless of fingerprint. If you use the same IP address at home every day, that address is a far simpler key than any canvas hash, which is why a secure browser is only part of the picture. And no fingerprinting resistance survives a browser that is out of date, because an exploited browser can read anything it likes.
Fingerprinting is best understood as one link in a chain that also includes cookies, IP addresses, logins and the data brokers who join them. Break the cheapest link for a tracker and it moves to the next one. The goal is not to be invisible, which is not on offer, but to make sure that clearing cookies actually means something and that a page you have never logged into cannot recognise you on sight. The rest of the picture is in the browser security hub.