Privacy & Anti-Fingerprint
Browser Fingerprinting Explained
Published: 2026-09-15 • 8 min read
Cookies get most of the public attention in discussions about tracking, in part because they are visible and easy to explain. Fingerprinting is less visible and, for that reason, harder to opt out of. It does not store anything on your device; it reads characteristics your browser already exposes and combines them into a value that can be surprisingly stable across visits.
What a fingerprint is actually made of
No single signal below is unique on its own. The technique works by combining many weak signals into one value that, together, narrows down to a small set of browsers, sometimes down to one.
| Signal | What it reveals | Why it is hard to hide cleanly |
|---|---|---|
| Canvas rendering | Subtle pixel-level differences from GPU, driver and font rendering | The output has to still look correct to the page, not just different |
| WebGL parameters | GPU vendor and renderer strings, and rendering precision quirks | Many legitimate sites query these for compatibility, not just tracking scripts |
| AudioContext output | Small differences in how audio processing is computed on different hardware | Changing it has to preserve normal audio playback behavior |
| Font enumeration | Which fonts are installed, often revealing OS, region and installed software | Removing fonts users need breaks normal page rendering |
| Hardware concurrency / memory | CPU core count and approximate device memory | Real values are useful for legitimate performance tuning by sites |
| Timezone and locale | Approximate location and language settings | Has to stay internally consistent with other reported settings |
| WebRTC local/public IP | Network information that can bypass proxy or VPN configuration | WebRTC needs real network information to establish connections at all |
The last column matters more than it might look. Almost every one of these signals exists for a legitimate reason: canvas and WebGL support real rendering, AudioContext supports real audio processing, font enumeration supports real typography, and WebRTC needs real network information to connect 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 random noise to one or two signals, such as slightly altering canvas output, is enough. In practice, fingerprinting scripts commonly cross-check signals against each other. A browser reporting a timezone that does not match its locale, or hardware concurrency that does not match its GPU-rendered canvas signature, produces a mismatch, and that mismatch is itself a distinguishing signal, sometimes a more identifying one than an untouched browser would have produced.
What this means in practice
Effective work in this space treats the browser as one coherent identity, not a list of independent knobs. Timezone, locale, language, hardware-reported 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.
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. Two problems come up quickly. First, the underlying engine has already computed the real value before your override runs, so anything the override does not think to touch will still leak. Second, overriding a native function changes what that function looks like when a page inspects it (for example via Function.prototype.toString), and some fingerprinting scripts check specifically for that signature to detect tampering.
Changing the same behavior inside the rendering engine itself, in Chromium’s or Firefox’s own C++ implementation, means the value a page receives is consistent from the source, with no detectable seam between “real” and “overridden.” It is also the only place where cross-signal coherence, timezone agreeing with locale agreeing with rendering output, can be enforced reliably.
Legitimate reasons teams work on this
- Privacy-focused browsers. Some browser products 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 physically provisioning each one.
- Fraud and abuse research. Security teams study these techniques to understand what tooling real attackers already use, and to build detection that accounts for it.
This is also why the work is scoped and documented rather than sold as a blanket guarantee. Our anti-fingerprint browser development page lists specifically which signals a build addresses and which it does not, because an honest account of coverage is more useful, and more defensible, than a claim that every tracking method is defeated.
What a written scope for this kind of work looks like
- Which specific signals are addressed: canvas, WebGL, AudioContext, fonts, hardware and client hints, WebRTC, timezone 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.
- What is explicitly out of scope, so a shipped build is never presented as more complete than it is.
Frequently asked questions
Is browser fingerprinting the same as tracking with cookies?
No. Cookies are data a site stores in your browser and reads back later; you can see, block or delete them. Fingerprinting instead combines characteristics your browser already exposes, such as screen size, installed fonts and how your GPU renders a canvas element, into a value that can identify a browser across visits without storing anything on it.
Does clearing cookies or using incognito mode stop fingerprinting?
Not on its own. Fingerprinting techniques generally do not rely on stored data, so clearing cookies or opening a private window does not change most of the signals a fingerprinting script reads. Incognito mode can change a few signals, but browsers vary in how much they adjust, and some fingerprinting methods are built specifically to detect a private-browsing state.
Can a browser extension fully prevent fingerprinting?
An extension can override some JavaScript-level APIs, such as returning a fixed value from a canvas read. It runs after the underlying engine has already produced its real answer, and a page can often detect that a native function has been overridden by inspecting it, which some fingerprinting scripts specifically check for. Coherent protection across many signals at once generally needs to happen inside the engine itself, not on top of it.
Why is randomizing values not enough on its own?
Fingerprinting scripts commonly compare multiple signals against each other, not just one. A browser that reports a timezone inconsistent with its locale, or a hardware profile inconsistent with its GPU-rendered canvas output, can stand out more than one with no protection at all, because the mismatch itself becomes a distinguishing signal. Coherent, cross-checked values matter as much as changing any single one.
Are there legitimate reasons to work on this beyond ad tracking?
Yes. QA and security teams use controlled fingerprint variation to test how a site or service behaves across device and browser profiles without provisioning physical hardware for each one. Privacy-focused browser vendors build fingerprint resistance directly into their products for users who want to limit cross-site tracking. Fraud and abuse research teams also study these techniques to understand what real attackers already use.
What does engine-level fingerprint work involve?
It means changing the C++ implementations inside Chromium or Firefox that generate values for canvas, WebGL, audio, font enumeration, hardware concurrency and similar APIs, so that the values a page reads are consistent with each other from the moment they leave the engine rather than being patched afterward at the JavaScript layer.
Final takeaway
Browser fingerprinting works because it draws on APIs that exist for good reasons, which is exactly why it cannot be switched off with one setting. Meaningful protection means treating a browser’s signals as one coherent identity and doing that work where the signals originate, inside the engine, with a clear, written account of what is and is not covered.
Working on privacy-focused browser features?
We implement fingerprint coherence work at the engine level in Chromium and Firefox builds, with a written account of what is covered.