A cookie is a name tag: the site hands it to you, and you show it on the next visit. A fingerprint is your face. Nobody hands it to you, you cannot take it off, and a site that has seen it once recognises it again without asking. This guide explains what the face is made of, how much of it is visible to a page, how sites use it, and what your options are, whether you want to be one person or several.
The one-paragraph definition
Browser fingerprinting is the practice of reading dozens of properties a browser exposes to every page, such as the User-Agent, screen size, installed fonts, GPU model, timezone and the exact way it draws an image, and combining them into an identifier. No single property identifies you. The combination usually does, because the odds that another visitor shares every value are small. The identifier is not stored on your machine, so clearing cookies and opening a private window do not touch it.
What goes into a fingerprint
| Group | Examples | How a page reads it |
|---|---|---|
| Identity | User-Agent, Client Hints, navigator.platform, vendor | Headers and navigator properties |
| Hardware | Screen size, CPU cores, device memory, GPU, media devices | screen, navigator, WebGL, WebGPU |
| Rendering | Canvas, WebGL image, audio processing, fonts, layout rects, speech voices | Drawing and measuring, then hashing |
| Locale | Timezone, offset, languages | Intl and navigator.languages |
| Network | HTTP IP, WebRTC candidates, IP-derived location | The request itself, plus WebRTC |
| Privacy signals | Do Not Track, storage behaviour, automation flags | navigator and storage APIs |
None of this requires a permission prompt. The Lab reads all of it in a few seconds, which is roughly what a fingerprinting script embedded in a page does on load.
How unique is it?
The EFF's 2010 study, the first at scale, found that 83.6% of browsers in its sample had a fingerprint that was unique among the half-million collected, and 94.2% among browsers with Flash or Java enabled. The properties available have grown since then (Canvas, WebGL and audio were not in that study), and the population of browsers has grown too, so the exact number moves, but the shape of the result has not changed: for most desktop browsers, the combination is identifying.
Two things make a fingerprint less unique: being a very common configuration (a fresh, default browser on a popular laptop model), or deliberately limiting what a page can read. Both are strategies, and they are covered below.
Why it survives everything you clear
A fingerprint is computed, not stored. The site calculates it from what your browser reports, keeps the result on its side, and calculates it again next time. There is nothing on your computer to delete. That is why Incognito does not change it, why clearing cookies does not change it, and why two Chrome profiles on one laptop share it.
It does change when the machine changes: a browser update, a new GPU driver, a new monitor. Those changes are slow and stable, which is exactly what sites expect. A Canvas hash that moves with every reload, by contrast, is not a changed machine; it is a modified browser.
How sites actually use it
Uniqueness is the headline, but consistency is what risk systems act on. A fraud engine rarely cares whether your GPU string is rare. It cares whether the GPU fits the operating system, whether the timezone fits the IP, whether the User-Agent fits the Client Hints, whether the WebRTC address fits the HTTP address, and whether the same fingerprint keeps appearing behind different accounts.
That produces three distinct uses:
- Recognition. The same fingerprint returns, so the site treats it as the same visitor even without cookies. Used for analytics, fraud prevention and paywalls.
- Linking. Two accounts share one fingerprint, or one fingerprint and one IP, so they are treated as one person. This is the one that matters for multi-account work.
- Contradiction. A fingerprint that could not belong to any real machine is treated as a bot or a modified browser, whatever it claims to be.
An unusual but coherent browser is one of many unusual real machines. A browser whose values contradict each other does not exist in the world, and that is the thing sites are built to notice.
Can you avoid it?
There are two honest strategies, and they pull in opposite directions.
Blend in. Make your browser look like as many other browsers as possible. The Tor Browser is the clearest example: it fixes the window size, the fonts and many other values so that every user looks alike, and it asks users not to customise anything. It works because everyone does the same thing. It stops working the moment you resize the window or install an extension, and it gives you one identity, not several.
Be someone specific, consistently. Present one complete, plausible machine, keep it stable over time, and never let its values contradict each other. This is the approach for anyone who needs a browser to look like a normal, particular person. Taken to its conclusion, it is also the approach for several identities: each one is a complete, plausible, stable machine of its own.
What does not work is the middle ground: randomising individual values, spoofing the User-Agent alone, or turning off APIs one by one. Each of those makes you rarer and, worse, inconsistent, so you fail on the second use above rather than the first.
See your own fingerprint
The fastest way to understand all of this is to look at your own. The Lab lists every group above for the browser you are using, shows the identifier that comes out of it, and flags the values that disagree with each other, which is the same cross-checking a risk engine does.
Check your own fingerprint
The Lab reads every signal above from your browser, builds the identifier, and highlights the rows that contradict each other. Nothing leaves your browser except one IP lookup.
How Mango Browser handles fingerprinting
Mango takes the second strategy and applies it per profile. Each profile is a complete machine: a Chrome/Chromium or Firefox identity on Windows or macOS, with the User-Agent and Client Hints, fonts, GPU renderer, screen, cores and memory all drawn from values real hardware reports and all consistent with the chosen operating system. Canvas, WebGL, audio and layout noise are seeded per profile, so each profile is unique across profiles and identical to itself on every draw.
Bind a proxy and the network and locale groups follow it: the WebRTC candidate matches the exit, and the timezone, language and geolocation can follow it automatically. Storage is a separate directory per profile. The result is what the cross-checks are looking for: one coherent browser per profile, and no shared value between profiles for a site to link on.