Clear your cookies, open an incognito window, and most people assume they are starting fresh and anonymous. They are not. Long before you log in or accept a consent banner, the page has already read several dozen facts about your machine and combined them into a stable identifier. That technique is called browser fingerprinting, and it works without storing anything on your device at all. There is nothing to delete, because the identifier is not saved on your side. It is computed on the server from signals your browser hands over for free, every visit, by design. This post takes the method apart signal by signal: what each one is, how many bits of identifying information it carries, how a handful of medium entropy signals multiply into something unique among millions, and why that matters for tracking, fraud, and deanonymization.
Why a fingerprint exists when nothing is stored
A cookie is a value the server asks your browser to keep and send back later. You can see cookies, count them, and erase them. A fingerprint is the opposite. The server does not ask you to store anything. It reads attributes your browser already exposes to make legitimate web pages work, and it derives an identifier from the exact combination of those attributes. A page needs your screen size to lay itself out. It needs your language to pick a translation. It can query your graphics stack to decide whether to use hardware acceleration. Each of these is reasonable on its own. The fingerprint is what you get when a script collects all of them at once and treats the bundle as a name.
Because nothing is written to your disk, the usual privacy reflexes do not touch it. Clearing cookies removes saved values, not the shape of your device. A private window blocks cookie persistence and history, not the screen resolution your monitor reports. The fingerprint survives both because it was never stored in the first place. It is recomputed from scratch on each visit, and as long as your machine and browser stay roughly the same, the result stays roughly the same.
It helps to separate two jobs the fingerprint does. First, recognition: deciding whether the browser in front of the server right now is one it has seen before. Second, linkage: tying together two separate sessions that the user believed were unrelated, such as a logged in visit and an anonymous one. A cookie does both jobs only as long as it survives. A fingerprint does both jobs without ever needing your cooperation, and that is the whole point. The server is reading you, not asking you to carry a tag.
The signals: what a page reads about you
Open the developer console on any page and most of these are one line of JavaScript away. None of them require a permission prompt. Here is the core set, grouped by how a script gets at them.
The easy attributes from the navigator and screen objects
The navigator object is a grab bag of properties the browser exposes about itself. The classic one is the user agent string, read with navigator.userAgent, which spells out the browser name, version, rendering engine, and operating system. A typical value looks like this:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Alongside it sit navigator.language and navigator.languages for your locale preferences, navigator.platform, navigator.hardwareConcurrency for the number of logical CPU cores, and navigator.deviceMemory for a rough memory figure. The screen object gives width, height, available width and height, and color depth. A single call to Intl.DateTimeFormat().resolvedOptions().timeZone returns your time zone as a clean string like America/New_York. Each of these is cheap to read and stable from one visit to the next.
Font enumeration
The exact set of fonts installed on a machine is surprisingly varied, because it reflects the operating system, the applications you have installed, and the language packs you have added. A script cannot ask for the full list directly anymore, but it can probe. It renders a string in a font it wants to test, measures the width and height of the result, and compares that against the measurement for a known fallback font. If the size differs, the requested font is present. Run that probe across a few hundred candidate fonts and the script reconstructs which ones you have. The presence or absence pattern is the signal.
Canvas rendering
This is where fingerprinting stops reading labels and starts measuring hardware. The HTML5 <canvas> element lets a script draw text and shapes, then read the resulting pixels back out. The trick, first described by Keaton Mowery and Hovav Shacham in their 2012 paper Pixel Perfect: Fingerprinting Canvas in HTML5, is that two machines asked to draw the exact same instructions do not produce the exact same pixels. A script draws a line of text, often with a mix of letters and an emoji, over a colored background, then calls toDataURL() to get the rendered image as a string and hashes it.
const c = document.createElement('canvas');
const ctx = c.getContext('2d');
ctx.textBaseline = 'top';
ctx.font = '14px Arial';
ctx.fillText('Cwm fjordbank glyphs vext quiz 😀', 2, 2);
const hash = sha256(c.toDataURL());
The canvas does not even need to be visible on the page. The output differs because the work of turning instructions into pixels runs through your GPU, your graphics driver, your installed fonts, and your operating system font rasterizer. Anti aliasing, sub pixel smoothing, and how an emoji is drawn all vary across an Intel integrated chip, an Nvidia card, and an Apple GPU. The differences are invisible to your eye and consistent on the same machine, which is exactly what a tracker wants.
This signal moved from research curiosity to mass deployment fast. In early 2014 the bookmarking company AddThis quietly ran canvas fingerprinting on a large share of the most visited sites on the web, a finding that drew attention because users had no way to see it happening and no setting to refuse it. That is the recurring shape of the problem. The data is read silently, the cost to the site is near zero, and the user is not told. A small study of canvas alone measured around 5.7 bits of entropy from the technique, which is not enough to name you by itself but plenty as one term in a larger product of signals.
WebGL
WebGL goes one level deeper into the graphics stack. A script can ask the WebGL context for the renderer string through the WEBGL_debug_renderer_info extension, and many browsers return the literal name of your graphics chip, something like ANGLE (Apple, Apple M2, OpenGL 4.1). Beyond the name, a script can render a 3D scene off screen and read the pixels back, the same idea as canvas but exercising more of the hardware. Shading, depth handling, and floating point rounding in the GPU pipeline differ across devices and show up in the output.
AudioContext
Audio fingerprinting applies the same logic to sound. A script creates an OfflineAudioContext, which processes audio as fast as it can without ever sending anything to your speakers. It generates a known waveform with an OscillatorNode, usually routes it through a DynamicsCompressorNode to magnify small differences, and reads the resulting samples back. Those samples are 32 bit floating point numbers. Because different audio stacks and CPUs round and process the signal with tiny differences, the values diverge at the far decimal places. Hash that buffer and you get another stable identifier, derived this time from your audio processing pipeline rather than your graphics. You never hear a thing.
The math: how browser fingerprinting turns weak signals into a unique name
No single signal here identifies you. Plenty of people use Chrome on macOS in the New York time zone. The power of browser fingerprinting comes from combining many signals that are each only moderately revealing. To see why, you need one idea from information theory: entropy, measured in bits.
The surprisal of an observation with probability p is -log2(p) bits. If half of all browsers share some attribute value, observing that value costs an attacker -log2(0.5) = 1 bit, and it cuts the candidate pool in half. If one in eight browsers share a value, that is -log2(1/8) = 3 bits, and it cuts the pool to an eighth. The entropy of a whole attribute is the average surprisal across all its possible values, written H = -Σ p(x) log2 p(x). The key property is that bits from independent signals add together. Each bit halves the number of people you could be.
Independence is the catch in that sentence, and it is worth being precise about. Bits add cleanly only when the signals do not correlate. In practice many do. Your operating system is implied by your user agent, hinted at by your font set, and reflected again in your canvas output. A tracker who naively sums the entropy of correlated signals overcounts, because the second signal tells them less once the first is known. Serious fingerprinting work measures the joint entropy of the whole bundle rather than adding the parts, which is why the headline numbers below come from full fingerprints, not from stacking the per signal figures.
A fingerprint does not need any single signal that names you. It needs enough independent signals that, multiplied together, only one person on earth fits all of them at once.
Put numbers on it. To be unique among the roughly 5 billion internet users alive today you need about log2(5,000,000,000), which is close to 33 bits of identifying information. That sounds like a lot until you tally what your browser gives away. In the original 2010 Panopticlick study, run by Peter Eckersley at the Electronic Frontier Foundation across 483,492 browsers, the measured entropy of individual signals looked like this:
- User agent string: about 5.1 bits
- Browser plugins: about 4.2 bits
- Installed fonts: about 4.1 bits
- Screen resolution and color depth: about 3.8 bits
- Time zone: about 3.6 bits
Those five medium strength signals already stack toward 20 bits when combined, enough to be one in roughly a million. Eckersley found that the full fingerprint carried at least 18.1 bits of entropy in that sample, which meant a randomly chosen browser had about a one in 286,777 chance of sharing its fingerprint with another. In practice 94.2 percent of the browsers that ran Flash or Java were outright unique. The dataset was a fraction of the global population, so 18.1 bits was enough to single out almost everyone in it.
The signals have shifted since then but the conclusion got stronger. Plugins and Flash are gone, which removed two of the richest old signals. In their place, canvas and WebGL became the heavy hitters. The 2016 AmIUnique study by Pierre Laperdrix and colleagues collected 118,934 fingerprints and found 89.4 percent of them unique, with canvas rendering now one of the most discriminating attributes. The reason a script reads your GPU through canvas, WebGL, and audio is that hardware variation is a deep, stable well of entropy that survives browser updates far better than a version number does.
Why a fingerprint stays stable
An identifier is only useful for tracking if it is the same tomorrow. Fingerprints are not perfectly stable. You update your browser and the user agent changes. You plug in an external monitor and the screen resolution changes. Eckersley measured this churn and found fingerprints shifted often, yet a simple heuristic still relinked more than 99 percent of changed fingerprints to their previous version, because usually only one attribute moves at a time while the rest hold.
The hardware derived signals are the anchor. Your GPU, your audio chip, and your installed fonts change far less often than your browser version. Canvas and WebGL hashes can stay identical across browser updates because they reflect silicon and drivers, not software labels. A tracker that sees most of your fingerprint stay constant while one field drifts can follow you across the change. The bundle is sticky even when its parts are not.
Why this is a privacy and security threat
The first harm is plain tracking. A fingerprint is a cookie that you cannot clear and did not consent to. Advertising and analytics networks use it to recognize you across sites and sessions even after you delete cookies or switch to a private window. It works in the exact moments people reach for privacy, which is what makes it worse than a cookie rather than equal to one.
The second harm is deanonymization. Suppose you use one browser profile for an ordinary logged in account and the same browser, in incognito, for something you want kept separate. If both sessions produce the same fingerprint, a service that sees both can tie them to one device. The anonymity you expected from a fresh window evaporates, because the device itself was the identifier the whole time. The same linkage works across sites that share data with a common third party. If an advertising network is embedded on two unrelated sites and both reads return the same fingerprint, that network can join your activity on both, no cookie required and no account needed.
There is a quieter harm that compounds the first two. Fingerprinting is not the only data that leaks about you without a prompt: a photo you share can carry hidden EXIF metadata such as the GPS coordinates where it was taken, which you can inspect and strip with our free EXIF metadata viewer and scrubber before you post it. Because a fingerprint is read passively, it can be collected before any consent dialog appears and without leaving an obvious trace in the browser. A user inspecting cookies and storage sees nothing unusual, because the identifier lives on the server side, derived from a few script calls that look like ordinary feature detection. The absence of a visible artifact is part of what makes the technique hard to govern. You cannot easily audit what you cannot see being stored.
The third use cuts the other way, toward defense, and it is worth being honest about. The same fingerprint that tracks you also helps fraud and account takeover systems. When your bank sees a login from an account it knows, on a device whose fingerprint it has seen many times, it can wave you through. When the same account suddenly logs in from a device with a fingerprint never seen before, that is a signal worth a second factor. Fingerprinting is a tracking threat and an anti fraud tool at the same time, and which one it is depends entirely on who is doing it and why. The mechanics are identical.
Defenses, and their honest limits
You cannot turn off fingerprinting the way you can clear a cookie, but you can shrink your entropy or muddy the signal. The approaches split into two camps, and both have real limits.
- Randomization. Some browsers add small noise to canvas, audio, and WebGL output so the hash differs on each read. Brave does this by default. The catch is that a fingerprint that changes every visit can itself be a recognizable trait, and a determined tracker can sometimes average the noise out across reads.
- Uniformity. The Tor Browser takes the other path. It tries to make every user look identical by standardizing the window size, blocking or faking many signals, and prompting before a canvas can be read. If everyone in the crowd looks the same, no fingerprint stands out. The cost is a more restricted browsing experience, and the protection only holds while you behave like the standard configuration. Resize the window or install an extension and you start to stand out again.
- Built in browser modes. Firefox ships resist fingerprinting and protection features, and Safari trims the data it exposes. These help, but vendors balance privacy against breaking real sites, so the protection is partial by design. Each blocked signal that a normal site relies on is a site that might break.
The uncomfortable truth is that better fingerprinting protection can make you more unique, not less, if it makes your browser behave unlike anyone else’s. Privacy here is a crowd problem. You are safest when you look like everyone around you, and most hardening makes you look different. For the full vocabulary around tracking, identifiers, and the attack surface of the browser, our web security glossary is a good companion. The research mindset that exposes fingerprinting in the first place, asking what a system quietly assumes and then testing it, is the same one behind how researchers find vulnerabilities.
The assumption that breaks
Every privacy tool aimed at the casual user rests on one assumption: that your identity online is a thing you store, so deleting what you stored makes you anonymous again. Clear the cookies, open a private window, wipe the history, and you are someone new. Browser fingerprinting breaks that assumption at the root. There was never anything stored on your side to delete. The identifier is your device, read live from the screen, the graphics chip, the fonts, the audio stack, the clock. You did not save it and you cannot erase it, because it is not a record. It is a measurement.
That is the gap worth sitting with. The thing people trust to make them anonymous, clearing local state, targets the wrong layer entirely. The fingerprint lives one level below, in the physical and configured reality of the machine, and that level does not reset when you clear your cookies. Anonymity online was supposed to be something you could reclaim by forgetting. Fingerprinting quietly turned it into something the device remembers for you.
Frequently asked questions
Does clearing cookies or using incognito stop browser fingerprinting?
No. A fingerprint is not stored on your device, so there is nothing to clear. It is recomputed on each visit from attributes your browser exposes, like screen size, time zone, installed fonts, and how your GPU renders a canvas. A private window blocks cookie and history persistence, not these signals, so the same fingerprint reappears. The Electronic Frontier Foundation explains this in its Cover Your Tracks project.
How many bits of information does it take to identify a browser uniquely?
Identity is measured in entropy, in bits, where each bit halves the pool of people you could be. To be unique among roughly 5 billion internet users you need about 33 bits. In the 2010 Panopticlick study across 483,492 browsers, the full fingerprint carried at least 18.1 bits of entropy, enough to give a roughly one in 286,777 chance of a collision, and 94.2 percent of browsers running Flash or Java were outright unique in that sample.
What is canvas fingerprinting?
Canvas fingerprinting asks the browser to draw text and shapes onto a hidden HTML5 canvas, then reads the pixels back with toDataURL() and hashes them. Two machines given identical drawing instructions produce slightly different pixels because of differences in GPU, graphics driver, fonts, and the operating system rasterizer. The technique was first described by Keaton Mowery and Hovav Shacham in their 2012 paper Pixel Perfect, and canvas is now one of the most discriminating fingerprint signals.
Is browser fingerprinting only used for tracking?
No. The same signals power tracking and deanonymization on the privacy invading side, and fraud detection and account takeover protection on the defensive side. A bank can recognize a known device by its fingerprint and challenge a login from a device it has never seen. The mechanics are identical. Whether fingerprinting is a threat or a safeguard depends on who collects it and why, which Mozilla covers in its MDN guide on fingerprinting.