Browser Fingerprinting Entropy, Explained

Every browser leaks small facts about itself: the fonts it can render, the way it draws a canvas, the order of its HTTP headers, the exact build of its JavaScript engine. On their own these facts are unremarkable. Combined, they can narrow a visitor down to one browser in millions. Entropy is the unit we use to reason about that narrowing, and it is the single most useful concept for anyone building or evaluating a fingerprinting system.

This article explains what entropy means in the context of browser fingerprinting, how to measure it, why raw uniqueness is not the whole story, and how stability changes the calculus. If you want the broader picture first, start with what device fingerprinting is and the device fingerprinting pillar.

What entropy actually measures

Entropy, in the Shannon sense, measures how much a signal narrows down the population. It is expressed in bits. Each bit halves the number of candidates. One bit splits the world in two; ten bits split it into 1,024 groups; 33 bits split roughly 8.5 billion people into groups of about one.

The formula for a single attribute is straightforward. If an attribute takes value i with probability p(i) across the population, its entropy is:

H = -Σ p(i) · log2(p(i))

A signal where every browser shares the same value carries zero bits. A signal where every browser has a unique value carries maximum bits. Most real signals sit in between. The Accept-Language header, for example, is highly predictable in some regions and highly distinctive in others.

The practical intuition:

• Common values carry little information. If 90 percent of visitors report the same timezone, knowing that timezone barely narrows anyone down.
• Rare values carry a lot. A browser reporting an obscure font set or an unusual GPU string stands out immediately.
• Entropy is population-relative. The same attribute can be worth 2 bits in one audience and 12 in another.

Where the bits come from

No single browser attribute is enough. Fingerprinting works by combining many partially independent signals so their bits add up. The classic contributors, each covered in its own guide, include:

• Canvas rendering, which reflects GPU, drivers, and font rasterization.
• WebGL parameters, exposing renderer and vendor strings plus precision quirks.
• Audio processing, where the audio stack produces subtly different output.
• Installed fonts, a strong discriminator on desktop.
• TLS handshake shape, captured server-side as a JA4 value.

The catch is that bits do not simply sum. Signals correlate. A browser reporting a specific GPU in WebGL will often produce a matching canvas hash, so the second signal adds less than its standalone entropy suggests. Realistic estimation uses joint entropy, not the sum of marginals:

Signal	Standalone bits (approx.)	Marginal add after canvas
Canvas hash	8 to 10	baseline
WebGL vendor	6 to 8	2 to 3
Font list	8 to 12	4 to 6
Timezone + language	3 to 5	3 to 5
Screen geometry	2 to 4	1 to 2

The numbers are illustrative and audience-dependent, but the shape is real: correlated signals overlap, and a good system measures the incremental contribution of each rather than double-counting.

Uniqueness is not identity

Here is the trap that catches newcomers. A fingerprint can be perfectly unique in a single measurement and still be useless for identification, because the same browser may produce a different value tomorrow. Browser updates change canvas output. A plugged-in monitor changes screen geometry. A privacy extension randomizes WebGL. Uniqueness is about this visit; identity is about matching across visits.

That is why a durable visitor ID is not just the hash of everything observed. It is the product of a matching process that tolerates drift in unstable signals and leans on the stable ones. A stable 20-bit fingerprint that survives browser updates beats a fragile 40-bit one that resets weekly.

This tension is exactly what a confidence score captures. Confidence reflects how strongly the current observation matches a known identity, given both the entropy and the stability of the contributing signals. Two visits with high joint entropy but conflicting stable signals should yield low confidence, not a false match.

Stability, drift, and the anonymity set

Think of every browser as belonging to an anonymity set: the group of browsers that share its observed values. High entropy shrinks that set. Perfect stability keeps a browser in the same set over time. Real systems manage both.

Practical tactics for handling drift:

• Bucket unstable signals. Round screen dimensions or quantize audio hashes so minor variation does not break a match.
• Weight by stability. Give durable signals like installed fonts more influence on the ID than volatile ones.
• Version the algorithm. When a browser release shifts canvas output for millions of users at once, detect the cohort shift instead of treating each device as new.
• Cross-check, do not concatenate. Use secondary signals to confirm a match rather than folding everything into one brittle hash.

Adversaries attack from the entropy angle too. Anti-detect browsers and canvas spoofing either flatten entropy to blend in or randomize it to break linkage. Flattening makes a browser suspiciously ordinary; randomization makes its signals internally inconsistent. Both are detectable precisely because natural browsers have a characteristic entropy profile that fakes struggle to reproduce.

Measuring entropy in your own traffic

You do not need a research lab to estimate entropy on your audience. Log the distribution of each signal, then compute per-signal entropy and, more importantly, the incremental bits each adds to your current identifier.

import math
from collections import Counter

def entropy_bits(values):
    counts = Counter(values)
    total = sum(counts.values())
    return -sum((c/total) * math.log2(c/total) for c in counts.values())

# per-signal entropy across your logged visitors
canvas_bits = entropy_bits(v.canvas_hash for v in visitors)
font_bits   = entropy_bits(v.font_set    for v in visitors)

Run this on your real population, not a synthetic one, because entropy is only meaningful relative to the audience you actually serve. A self-hosted deployment makes this easy: the raw signal distributions stay in your infrastructure, so you can audit exactly which signals earn their keep and drop the ones that add cost without bits.

Frequently asked questions

How many bits of entropy do you need to identify a browser?

Roughly 33 bits are enough to distinguish one browser among about 8.5 billion, but practical systems combine many weaker signals and lean on stability rather than raw uniqueness.

Does more entropy always mean a better fingerprint?

No. High entropy that changes between visits is worse than moderate entropy that stays stable, because identification depends on matching the same value over time.

Can users lower their own entropy?

Yes. Anti-detect browsers and randomizers reduce distinguishing bits or rotate them, which is exactly why modern systems weight stability and cross-check signals.

Entropy is the right mental model for fingerprinting, but it is only half of it. The other half is stability. Measure both on your own traffic, weight signals by how much durable information they contribute, and you will build identifiers that hold up under browser churn and adversarial pressure. Explore the playground to see live entropy contributions, or read the glossary for the surrounding vocabulary.