Browser Fingerprinting Explained: Why Hardening Your Browser Can Make You Easier to Track

Blocking cookies feels like the end of tracking. It isn’t, and hasn’t been for over a decade. A site can identify your browser across visits without storing anything on your machine at all — purely from the combination of details your browser volunteers to render a page correctly.

The mechanism is worth understanding precisely, because the intuitive defense against it — turning on more privacy settings — sometimes makes things worse.

A fingerprint is a combination, not a secret

No single thing your browser exposes identifies you. Your timezone is shared with hundreds of millions of people. Your screen resolution is one of maybe a dozen common values. Your browser version is shared with everyone who updated this week.

The identification comes from the conjunction. Timezone Europe/Berlin and screen 2560×1440 and 12 CPU cores and this exact GPU string and this font set and this language list — each is common, and the intersection is often a set of one.

The right unit for this is entropy, measured in bits. One bit of entropy halves the population. If a signal’s value splits the world in two, that’s 1 bit. Twenty bits distinguishes one in roughly a million.

The foundational measurement is the EFF’s Panopticlick study, published by Peter Eckersley in 2010. Across over a million visits, it found that 83.6% of browsers had a completely unique fingerprint, and that the distribution carried at least 18.1 bits of entropy — meaning a randomly chosen browser was expected to share its fingerprint with only 1 in about 286,777 others. Among browsers with Flash or Java enabled, it was worse: 94.2% unique, 18.8 bits.

The per-signal breakdown from that study is still the clearest illustration of where identification actually comes from:

Signal	Entropy (bits, Eckersley 2010)
Browser plugins	15.4
Installed fonts	13.9
User agent	10.0
HTTP headers (Accept, etc.)	6.1
Screen size and color depth	4.8
Timezone	3.0
Supercookies	2.1

What changed since 2010 — and what didn’t

That table is 16 years old, and two of its three biggest entries are gone. Flash and Java are dead, browser plugin enumeration has been removed or neutered everywhere, and direct font enumeration is heavily restricted. If fingerprinting were static, the problem would have shrunk dramatically.

It didn’t shrink, because new surfaces appeared:

• Canvas fingerprinting. Draw text and shapes to an off-screen <canvas>, then hash the pixels. The result varies by GPU, driver, font rasterizer, and anti-aliasing settings — so the same drawing instructions produce measurably different pixels on different machines. It requires no permission and leaves no trace. The technique was demonstrated academically by Mowery and Shacham in 2012 and was in widespread commercial use within two years.
• WebGL vendor and renderer strings. These often name your actual GPU. ANGLE (NVIDIA GeForce RTX 4070 Direct3D11 vs_5_0 ps_5_0) is a very specific string.
• AudioContext fingerprinting. Process an audio signal through the Web Audio API and hash the output. Floating-point differences across audio stacks produce a stable identifier.
• hardwareConcurrency and deviceMemory. Your CPU core count and rough RAM tier, available to any script for the asking.
• Timing and behavioral signals. Rendering performance, JS engine timing quirks, and — in more aggressive setups — how you move and type.

Meanwhile browsers pushed back. Chrome’s User-Agent reduction froze most of the detail in the UA string and moved the rest behind Client Hints that a site must explicitly request. Safari reduced its exposed surface and reports a deliberately generic system profile. Firefox ships privacy.resistFingerprinting, which standardizes many values outright. (The full story of what got frozen and what replaced it is in why every User-Agent string looks the same now.)

The result is an arms race that is roughly at a stalemate: the easy signals got worse, the hard ones got better.

Why bit totals are almost always overstated

Here’s a thing most fingerprint-checking sites get wrong, sometimes dramatically.

You’ll see a tool sum the entropy of each signal it measures and announce “your browser has 34.7 bits of entropy — you are unique among 27 billion.” That number is essentially always too high, for one reason: the signals are correlated, and entropy only adds when signals are independent.

Consider: a user agent saying macOS, a WebGL renderer saying “Apple M3 Pro,” a platform of MacIntel, and a screen resolution of 3024×1964. Naively that’s four signals worth maybe 20 bits. In reality, knowing the first one makes the other three far more predictable — Apple sells a small number of configurations. The joint entropy is much lower than the sum of the parts.

The honest way to measure fingerprint uniqueness is to compare against a real population — which is what Panopticlick and its successor Cover Your Tracks do, by holding a corpus of real fingerprints and telling you how many matched yours. A tool that can’t see a population can’t compute that number, and shouldn’t pretend to.

That’s a deliberate design choice in our browser fingerprint test: it shows the per-signal entropy estimates as clearly-labeled figures in the spirit of Eckersley’s numbers, but the verdict it gives you is based on how many signals your browser was willing to answer — not on a summed bit count. Signal coverage is something a purely local tool can actually stand behind. “You are one in 27 billion” is not, and a naive bit sum would tell essentially every visitor they were near-unique, which is scary, impressive, and not measurement.

The counterintuitive part: privacy settings as a fingerprint

This is the piece that changes how you should think about defending yourself.

Suppose you install a niche user-agent spoofer, disable canvas, block WebGL, set a rare non-default font stack, and pick an unusual window size. Every individual change removes a signal. And yet you may now be more identifiable, because the configuration itself is rare.

If 0.01% of users have your exact combination of blocked APIs, then “this browser blocks canvas, reports a spoofed UA, and has WebGL disabled” is itself a high-entropy signal. You’ve traded several common values for one very uncommon one. Worse, spoofers are often detectably inconsistent — a UA claiming Windows alongside a platform of MacIntel, or a canvas API that’s present but returns implausible output — and inconsistency is a stronger identifier than either honest value would have been.

Which is why the two strategies that actually work run in opposite directions from “add more tweaks”:

1. Blend in. This is the Tor Browser approach: make every user’s fingerprint identical, by standardizing screen size (via letterboxing), timezone, fonts, and language for everyone. You’re not hiding in the dark; you’re hiding in a crowd of identical people. It only works if you don’t customize it — every personalization you add to Tor Browser damages exactly the protection you installed it for.
2. Reduce the surface uniformly, at the browser-vendor level. Chrome’s UA reduction and Safari’s generic profile work because they apply to everyone at once. A change that only you make is a signal. A change the vendor ships to a billion users is not.

The individual-user version of this is unglamorous: use a popular browser in a near-default configuration, keep it updated, and layer defenses that don’t alter your fingerprint — a content blocker that prevents trackers from loading at all, and where anonymity genuinely matters, Tor Browser as-shipped. A widely-used blocker like uBlock Origin blocks the script before it runs, which is meaningfully better than letting it run and feeding it lies.

What this actually buys a tracker

Worth calibrating, in both directions.

Fingerprinting is less reliable than cookies. Fingerprints drift: you update your browser, plug in a monitor, install a font, change a setting. Commercial fingerprinting therefore uses fuzzy matching and confidence scores, not exact hashes, and it degrades over weeks. For high-stakes identification it’s a heuristic, not proof — which is why session hijacking still goes after the real thing: actual cookies and tokens, which leak through pasted curl commands and HAR files far more often than through fingerprints.

But it is more persistent than cookies in the ways that matter for tracking. It survives clearing your cookies, survives private browsing (which discards storage, not hardware characteristics), and requires no consent dialog — which is precisely why regulators have taken an interest. Under GDPR and the ePrivacy Directive, fingerprinting for tracking generally requires consent on the same basis as cookies, because the rule is about accessing information on a user’s device, not about the specific technology. Enforcement has been uneven, and disclosure is often buried.

It’s also genuinely used for anti-fraud — detecting that a login is coming from a device that has never been seen on this account before. That use is defensible and widespread, and it’s the reason fingerprinting won’t be legislated out of existence: the same technique that tracks you across sites also stops your bank account being drained.

See your own

• Browser Fingerprint Test — every signal your browser hands over, what each one contributes, and a verdict based on signal coverage rather than an inflated bit total. Runs entirely locally; nothing is transmitted or stored.
• What Is My IP — the other half of the identification picture, and the one a VPN actually addresses.
• User Agent Parser — decompose the UA string itself.

The network layer has been through the same arms race: Wi-Fi MAC addresses were a stable per-device identifier until the major platforms started randomizing them by default, which is why MAC vendor lookup now fails on phones.

For the neighboring problem of data you’re leaking on purpose, see why regex PII redaction always leaks and does your photo leak your location.