What is a browser fingerprint?

Every browser announces a great deal about itself on every page load, and none of it requires storing anything on the visitor’s machine. A browser fingerprint is what a website assembles from that ambient detail. The phrase has been around since 2010, but the meaning has shifted; the useful modern framing is a compact, engineered view of a session that helps you decide whether to trust it.

The long version of that idea follows: the working definition, the seminal research, what signals a fingerprint is actually made of, how stable any of it is in practice, and how the term differs from related concepts like device fingerprinting and visitor identity.

Live Your fingerprint, right now

Estimated rarity

Collecting…

This is a toy fingerprint. Values are real (collected from your browser via standard JS APIs and never leave the page), but the rarity badges and entropy total are rough heuristic approximations, not measured against a real population.

A working definition

A browser fingerprint is a set of properties a server can collect from a visiting browser, combined into a representation that distinguishes one session from another. The properties come from HTTP request headers, JavaScript APIs that report environment details, the results of running small probes (for example, rendering a string with the HTML5 canvas), and lower layer signals like the TLS handshake.

The output is sometimes a single hash, sometimes a vector of values, and sometimes several specialized representations evaluated side by side. Whatever the shape, the server can recognize the browser later or group it with others that look alike, without writing anything to the device.

Two things follow from that definition.

First, a fingerprint is not consent based. The browser ships these properties on every request because protocols and APIs were designed to expose them for non-tracking reasons (font fallbacks, capability detection, debugging, locale handling). That makes fingerprinting hard to opt out of in the traditional sense and also makes it the most reliable way to recognize a session that is actively trying to look fresh.

Second, “browser fingerprint” is a category, not a single technique. Canvas fingerprinting, TLS fingerprinting, audio fingerprinting and font enumeration are all separate methods that produce separate representations. They get combined because no single signal carries enough information on its own.

The research that gave us the term

The concept entered the security literature with a landmark 2010 EFF study: Peter Eckersley’s How Unique Is Your Web Browser?. Eckersley ran a public experiment at panopticlick.eff.org and collected around 470,000 fingerprints over a few weeks. The field has been building on his framing ever since.

His result became the canonical fingerprinting number. The distribution he observed had at least 18.1 bits of entropy, which meant that picking a browser at random put it in a bucket shared with roughly one in 286,777 others. About 83.6% of fingerprints in the sample were unique, rising to 94.2% when Flash or Java were enabled (Eckersley 2010, PDF). That study is the reason “fingerprint” is the word we use.

Four years later Pierre Laperdrix and colleagues ran a larger study called AmIUnique on around 118,000 fingerprints. They confirmed that the basic effect was holding (89.4% unique in their dataset) but also began to map how the attribute mix was shifting as plugins like Flash were retired and as mobile browsers entered the picture (Laperdrix et al., 2016 survey).

Long-term measurements followed. A PETs paper from 2020 studied fingerprint evolution over six months and reported that more than 90% of attributes typically remain unchanged across consecutive observations of the same browser, while the practical “trackable” window where the full fingerprint stays recognizable is closer to 1.8 weeks (Vastel et al., PoPETs 2020). That gap between attribute stability and fingerprint stability is one of the most important things to internalize. We will come back to it.

What a browser fingerprint is actually made of

Most production fingerprinting systems collect from five overlapping layers. None of them are particularly clever in isolation, which is the point. Their information value comes from how they combine.

HTTP headers and protocol behavior. The User-Agent, the Accept-Language and Accept-Encoding lists, header order and casing, and the Sec-Fetch and Client Hints headers modern Chromium sends. One layer down, the TLS handshake exposes the cipher suites and extensions the client offers, captured in fingerprints like JA3 and JA4. A Python requests script, a Go binary on the standard net/http stack and a real Chrome produce visibly different TLS fingerprints even when the application code claims they are all Chrome.
Environment and capability properties from JavaScript. The Navigator and Screen APIs report the platform string, language list, hardwareConcurrency, deviceMemory, screen geometry and color depth; the WebGL RENDERER string exposes the GPU; the installed font set can be enumerated indirectly. Each is a low-bit signal taken alone, but the joint distribution thins out fast.
Active probes and rendering tests. Canvas, WebGL and AudioContext probes ask the browser to render or synthesize something, then hash what comes back. The result encodes hardware and driver behavior that no API reports directly. These probes produce the largest single chunks of entropy, and they are the main reason the signal surface in 2026 is far wider than what Eckersley had to work with in 2010.
Behavioral and interaction signals. Mouse trajectories, scroll velocity, keystroke and copy-paste timing. None of this identifies a device; it separates humans from headless scripts, and it keeps working even when the device-layer fingerprint is being deliberately rotated. Mature systems treat it as its own representation rather than mashing it into the fingerprint hash.
Network and infrastructure. The IP address, its ASN and hosting classification (datacenter, residential ISP, mobile carrier), proxy presence, known abuse history, and the gap between the user-claimed time zone and the IP-implied geography.

Each of these layers is a deep topic in its own right. Browser fingerprinting techniques walks through every signal with code and concrete examples, and device fingerprinting in JavaScript shows what the collection actually looks like in a browser SDK.

A note on entropy

Entropy is the bookkeeping unit for fingerprinting. One bit of entropy halves the population that matches the signal. Eckersley’s 18.1 bits put the average browser in a group of around 286,000 out of half a million. Modern measurements on richer attribute sets are higher (one large study reports 81% unicity across roughly 2 million browsers using 216 attributes), but the qualitative point has not changed. Combining low-entropy signals quickly produces high-entropy joint distributions.

Interactive How signals combine into entropy

Cumulative entropy after all signals

0.0 bits · 1 in ,

Illustrative, not measured. Per-signal bit estimates are taken from published studies (Eckersley 2010, Laperdrix 2016, Vastel 2020) and approximate the entropy each category contributes on average. The cumulative total applies a correlation discount and caps at the ~22 bit ceiling those studies observed in real populations.

That arithmetic matters because attackers know it. Single-signal fingerprinting can be defeated by spoofing one or two values. Joint-distribution fingerprinting is much harder to defeat because you have to spoof every signal in a way that is internally consistent across all the layers above.

How stable is a fingerprint, really?

Here is where the field has matured the most. The honest answer has two parts.

Per-attribute stability is high. The 2020 PETs study reported that on average, 91% of individual attributes are unchanged when you observe the same browser six months apart. Hardware does not change. The GPU model does not change. Most of what the OS reports does not change. Even the canvas readback is identical across days as long as the driver does not update.

Live probe Re-render the same canvas, five times

Identical hashes

This one is real. Each canvas above is genuinely rendered by your GPU and driver, then SHA-256 hashed. The "5 of 5 identical" result demonstrates the actual stability of canvas fingerprinting on your hardware. Open this page in a second browser on the same machine and the hash will differ, not because the hardware changed but because Chrome, Firefox, and Safari each use different PNG encoders.

Exact-match fingerprint stability is short. The same study put the typical “trackable” window of a hash-based fingerprint at about 1.8 weeks. A browser update changes the User-Agent. An OS minor version bump changes a font set. A driver update changes a canvas readback. Any of those single changes invalidates an exact hash even though 90+% of the attributes are still the same.

In practice this means anyone who treats a fingerprint as a primary key will lose recall in production, and building on the raw hash is the most common architectural mistake in the field. A hash that drifts with every browser update may be unique, but it is too unstable to support anything that lasts longer than a few weeks. Either you bucket on per-attribute matching (fuzzy match), or you fold the fingerprint into a server-side identity that survives small changes, or both. The architecture that works is a stable server-side identifier that consumes the fingerprint as one input among several.

”Browser fingerprint” vs “device fingerprint” vs “visitor ID”

The three phrases get used interchangeably in marketing copy and they mean different things in practice.

Browser fingerprint. A representation built from what the browser exposes. Tied to one browser instance on one device.
Device fingerprint. A representation that targets the underlying device rather than the browser. Includes signals like CPU, GPU, OS-reported hardware properties and sometimes mobile platform attestation. The same device viewed from two different browsers can produce two different browser fingerprints but should produce one consistent device identity if the system is built for it.
Visitor ID. The stable server-side identifier the system actually returns. It is derived from one or more fingerprint representations plus server-side memory of past observations, and it is what application code should use as a key.

Foil calls the stable cross-session identity a visitor fingerprint and treats individual fingerprints as the inputs that resolve into it. The vocabulary is not standardized across the industry; the architectural distinction is.

Use cases worth distinguishing

The reason browser fingerprinting has both a privacy-research literature and a fraud-detection literature is that the same technique serves opposite goals depending on who deploys it and why.

Ad tracking is the case the privacy literature focuses on. An ad network embedded across thousands of sites uses fingerprinting to recognize the same browser everywhere and tie it to a profile. The browser cannot opt out and usually does not know it is happening. This is what regulators object to and what extensions like CanvasBlocker target.

Fraud and abuse detection is the case the security literature focuses on. A single application uses fingerprinting to recognize its own returning users, detect ban-evading multi-accounting, identify automation, and reduce login or checkout friction for known-good devices. The data stays inside that application boundary and never leaves it for cross-site profiling.

These two cases use overlapping techniques and have completely different ethical loads. Treating them as the same thing is the source of most confused product positioning in the category.

Why a single fingerprint is rarely the whole answer

There are three reasons.

Spoofing is one-signal at a time. Anti-detect browsers like Multilogin, Octo, Dolphin and AdsPower exist to give automation operators a way to present a clean, plausible fingerprint per account. They are getting better at it. Raising the entropy of a single fingerprint does not help much against them. What does help is multiple representations across multiple layers that all have to be internally consistent. A spoofed User-Agent that does not match the TLS fingerprint that does not match the timezone that does not match the GPU is what catches sophisticated automation (anti-detect browser detection covers the cat-and-mouse in detail).
Stability requires server-side resolution. A hash that ages out in two weeks does not survive contact with the use cases that matter. Fraud detection needs identity that survives a Chrome update.
Different fingerprints answer different questions. A canvas fingerprint is good for cross-account linking on the same device. A TLS fingerprint is good for clustering automation frameworks. An interaction fingerprint is good for separating scripted from human-driven traffic. Forcing them into one number throws away information.

How Foil thinks about it

Foil treats a session as a structured set of representations rather than a single fingerprint hash. Each layer (HTTP, TLS, JS environment, active probes, interaction, network) produces its own evidence. The server-side resolver combines them into a stable visitor fingerprint that survives small attribute changes, and into a verdict and per-signal evidence that explain why a session is being scored a particular way. In that architecture the hash is one useful component among several rather than the product itself.

If you want the technical surface area covered in detail, the next two posts are worth reading: browser fingerprinting techniques walks through each signal layer with examples, and canvas fingerprinting goes deep on the highest-entropy active probe.