Browser fingerprinting explained

Cookies get most of the attention in discussions about tracking, partly because they are visible and easy to explain. Fingerprinting is less visible and harder to opt out of: it reads characteristics your browser already exposes and combines them into a value that can stay stable across visits.

Research has found fingerprints to be identifying in large samples. The EFF’s 2010 Panopticlick study found about 84% of browsers had a unique fingerprint, and the 2016 AmIUnique study found about 89%. A 2018 study of around two million visitors to a large French website found only about a third were unique. Uniqueness depends heavily on the population measured, but it is rarely low enough to ignore.

What a fingerprint is made of

No single signal below is unique on its own. The technique works by combining many weak signals into one value that narrows down to a small set of browsers, sometimes to one.

The last column matters more than it might look. Almost every one of these signals exists for a legitimate reason: canvas and WebGL for rendering, AudioContext for audio processing, font enumeration for typography, and WebRTC for calls. Fingerprinting is a side effect of useful APIs, not a single flaw that can be patched out.

Why coherence matters more than any single value

A common assumption is that adding noise to one or two signals, such as canvas output, is enough. In practice, fingerprinting scripts cross-check signals against each other. A browser that claims to be Chrome on Windows but exposes macOS-only fonts, or an iPhone User-Agent paired with a desktop NVIDIA WebGL renderer string, is flagged at once, and more reliably than an unmodified browser would be.

What this means in practice

Effective work in this area treats the browser as one coherent identity, not a list of independent knobs. Time zone, locale, language, hardware values and rendering signatures all need to agree with each other and stay consistent across a session, rather than being randomized independently on every page load.

Two defensive strategies: blend in, or vary consistently

Tor Browser makes every user report the same values where it can, so no one stands out. Brave instead adds small amounts of noise to values such as canvas and audio output, seeded per site and per session, so values stay stable during a visit but cannot be linked across sites. Both work only when every signal agrees with every other. Randomizing each value on every call fails because it is inconsistent, not because it is random.

Why this usually needs engine-level changes, not just an extension

A browser extension runs JavaScript that can intercept some calls, for example wrapping HTMLCanvasElement.prototype.toDataURL to return an altered value. Three problems come up quickly. First, anything the override does not think to touch still leaks the original value. Second, overriding a native function changes what it looks like when a page inspects it (for example through Function.prototype.toString), and some fingerprinting scripts check for exactly that. Third, a page can get untouched copies of the APIs from a fresh iframe, a web worker or an OffscreenCanvas, unless the override reaches those contexts before the page uses them.

Changing the same behavior inside the engine, in Chromium’s or Firefox’s own C++ implementation, means the page sees native functions rather than script overrides, and every context (frames, workers, offscreen canvases) gets the same values. Altered outputs can still be spotted by careful statistical tests, so this is not invisibility. It is the most reliable place to enforce cross-signal coherence: time zone agreeing with locale, and both agreeing with rendering output.

Legitimate reasons teams work on this

• Privacy-focused browsers. Some browsers build fingerprint resistance in directly, as a user-facing privacy feature rather than a hidden default.
• QA across device and browser profiles. Testing how a site or web app behaves across many device, OS and browser combinations without provisioning each one physically.
• Fraud and abuse research. Security teams study these techniques to understand the tools attackers already use, and to build detection that accounts for them.

Fingerprinting itself also has legitimate users: banks and fraud-prevention vendors use it to detect account takeover and bots. In the EU, regulators treat reading device characteristics for tracking as covered by the ePrivacy consent rules (EDPB Guidelines 2/2023).

Whatever the use case, this work should be scoped and documented, not sold as a blanket guarantee. Our browser security and anti-fingerprinting service delivers a written list of which signals a build covers and which it does not. For examples, see the Anti-Fingerprint Chromium Browser and Symphony Browser case studies.

What a written scope for this kind of work looks like

• Which signals are addressed: canvas, WebGL, AudioContext, fonts, hardware and client hints, WebRTC, time zone and locale, or a subset.
• Whether protections are applied at the engine level, and where JavaScript-level fallbacks are used instead, with the tradeoffs of each documented.
• How consistency is verified, ideally with a reproducible test harness that checks signals against each other, not just against a baseline.
• Which public test pages are used as a baseline, for example Cover Your Tracks, AmIUnique and CreepJS.
• What is explicitly out of scope, so a shipped build is never presented as more complete than it is.