What Is Browser Fingerprinting? How It Works and What It Can Identify

Browser fingerprinting is a method of recognizing a returning visitor by the technical characteristics of their browser rather than by a cookie or a login. The browser reveals dozens of small details as it renders a page, and combining them produces an identifier that is stable enough to recognize the same browser on a later visit. The technique dates to the late 2000s, when researchers first measured how much a browser gives away, and it has grown more precise as browsers gained more capabilities to measure. What it identifies is narrower than most descriptions of it suggest: a browser environment on a device, not a person and not a device.

What a Browser Fingerprint Actually Is

A browser fingerprint is a hash derived from the configuration and rendering behaviour of a browser: its screen properties, installed fonts, graphics output, audio stack, language settings and similar attributes. Individually these details are common. Combined, they form a value distinctive enough to recognize that browser when it returns, without storing anything on the visitor's machine.

The useful measure here is entropy: how much each signal narrows the field. Screen resolution alone might place a visitor in a group of millions. Add the exact set of installed fonts, how the graphics card renders a test image, and the browser's language and timezone, and the group shrinks fast. Uniqueness is the practical expression of that: the share of visitors whose fingerprint no one else shares.

That number is never 100%. Two devices bought at the same time, running the same operating system, browser version and default settings can produce the same fingerprint. Fingerprinting is a probabilistic signal, and treating it as a certainty is the most common way teams get it wrong.

The table below places the technique against the two identifiers most teams already use, on the properties that usually decide between them.

How Browser Fingerprinting Works: The Signals

A fingerprint is assembled from several families of signal, each contributing a different kind of entropy. What follows is an overview of the families; our guide to browser fingerprinting techniques covers how each one is collected in detail.

Canvas and WebGL. The browser is asked to draw an image or render a 3D scene off-screen, and the exact pixel output is hashed. Because the result depends on the graphics processing unit (GPU), driver version, and font rasterization, it varies measurably between machines. This is usually the highest-entropy single signal available, and canvas and WebGL fingerprinting explains how the rendering differences arise.

Audio. A short waveform is processed through the browser's audio stack and the output is measured. Differences in the audio processing implementation and underlying hardware produce small but consistent variations. Our guide to audio fingerprinting covers how the signal is generated and how stable it is in practice.

Fonts. Which fonts are installed, and how each renders at a given size, reflects the operating system, the applications installed, and any fonts the user added. It is a strong discriminator between otherwise similar machines.

Screen and hardware. Resolution, colour depth, pixel ratio, reported device memory and the number of logical processors are all readable from JavaScript. Each is low entropy alone and useful in combination.

Locales. Language preferences and timezone are cheap to read, reasonably stable, and carry rough geographic information without any network lookup.

Network and transport. Server-side, the Transport Layer Security (TLS) handshake and the ordering and content of HTTP headers form a signature of the client software. These cannot be read from JavaScript, so they are only available to services that observe the connection itself.

One family that appears in older descriptions of fingerprinting does not belong here. Typing rhythm, mouse movement and scroll behaviour are behavioural biometrics, a separate discipline with different data collection, consent implications and failure modes. They are not part of a browser fingerprint.

What Browser Fingerprinting Can and Cannot Identify

This is where most published explanations, including vendor ones, quietly overreach. A browser fingerprint identifies a browser environment on a device. Every signal it uses is observed through the browser, so the resulting identifier binds to the browser and device together, no matter how many of the underlying signals describe hardware.

Within that scope it is durable. The same browser is recognized after the visitor clears cookies, after a session expires, and in a private or incognito window, because none of those actions change the rendering and configuration characteristics being measured. That durability is the entire reason the technique is used.

Outside that scope it does not work, and no JavaScript solution changes this:

• A different browser on the same machine is a different fingerprint. Chrome and Firefox on one laptop render canvas differently and expose different plugin and permission sets. Two browsers on one machine share every hardware attribute and still do not match.

• A different device is a different fingerprint. There is nothing to match a laptop visit against a phone visit without a login.

• Native mobile apps are outside the technique entirely. Fingerprinting runs in a browser. App-based identification uses platform SDKs and is a different product category.

The boundary runs the other way too. Because a fingerprint describes the browser rather than the person using it, two people sharing one browser look like a single visitor, and a shared family or office machine will not separate them. Telling those people apart means observing how each one behaves rather than what their browser is. That is behavioural biometrics, and the heavier collection it requires is the price of the extra resolution.

One more limitation is worth planning around. Where connection details form part of the fingerprint, a visitor who changes browser and network at the same time will not match, because both halves of the signal moved together. Design for a probabilistic match rather than a guaranteed one.

The scope question is also why terminology matters here. "Device fingerprinting" is widely used for the same JavaScript technique, which invites the assumption that the identifier follows the hardware. It does not. Our explainer on browser fingerprinting and device fingerprinting covers where the two terms genuinely differ.

Where Browser Fingerprinting Is Used

Fingerprinting earns its place wherever a system needs to recognize a returning visitor who has not logged in and cannot be relied on to carry a cookie.

Fraud and abuse prevention. Repeat offenders clear cookies and open incognito windows as a matter of routine, so cookie-based history is close to worthless against them. A fingerprint gives fraud teams a persistent handle for detecting duplicate signups, repeat promo redemptions and suspicious login patterns. It is one input to a risk model rather than a verdict on its own, which matters most in payment fraud detection, where a false positive blocks a real customer.

Bot and traffic quality. Automated traffic is often distinguishable by connection and transport characteristics before any behaviour is observed. Fingerprinting supports bot detection by flagging clients whose transport signature and browser signals do not fit together, such as a browser claiming to be Chrome on macOS over a datacenter connection.

Cross-domain attribution. A visitor journey often spans two domains, from a content or comparison site to the booking or checkout site that completes the purchase. Cookies break at the domain boundary by design, so the two halves arrive as unrelated visitors and the referring site goes uncredited. The same browser produces the same fingerprint on both domains, so the visits can be matched server-side and the journey stitched back together. This is the mechanism behind affiliate, travel and multi-site attribution, and our write-up on using a fingerprint as a cross-domain storage key works through one implementation. Note why it works: the domain changes, the browser does not.

Returning-visitor recognition and personalization. Product teams use fingerprinting to keep a cart, a set of preferences or a metered article count attached to a visitor who never creates an account, the foundation of cookieless website personalization. The scope limit is a design constraint here, not a footnote: continuity holds within a browser, so a shopper moving from laptop to phone starts fresh unless they log in.

Across all of these, "identification" needs care: anonymous website visitor identification covers two different capabilities, recognizing a returning visitor and attaching a name to them. Fingerprinting does the first and not the second.

Browser Fingerprinting, Privacy, and Consent

Fingerprinting is contested, and a builder should understand why before deploying it. It works without user action, produces no artefact a visitor can inspect or delete, and was widely used for cross-site advertising before browsers pushed back.

Browsers were not the only ones to respond. Regulators have moved from silence to an explicit position, and it is mostly clarifying. In Guidelines 2/2023, finalised in October 2024, the European Data Protection Board placed device fingerprinting inside the scope of Article 5(3) of the ePrivacy Directive, alongside tracking pixels and certain IP tracking. Fingerprinting is treated like cookies rather than as an unregulated grey area, which means a well-understood path to using it lawfully rather than an open question.

Where scrutiny bites is on purpose rather than technique. When Google told advertisers it would stop prohibiting fingerprinting from February 2025, the ICO called the change "irresponsible" and restated its view that fingerprinting "is not a fair means of tracking users online". That objection is about cross-site advertising. A first-party fraud, security or continuity deployment is a different conversation with different obligations.

Which conversation you are in depends on the use case and the jurisdiction. Whether a given deployment needs consent is a question for legal advice on the implementation rather than something a vendor page can answer. What helps in every case is being able to state plainly what the fingerprint identifies, how long it is kept, and what it is used for.

Where Browser Fingerprinting Is Heading

Three developments are shaping how well the technique will work over the next few years, all of them already visible in shipped browsers. The short version is that fingerprinting is getting harder to do naively and more dependable when it is done properly.

Browsers are narrowing what scripts can read. Brave randomizes canvas and audio output per site and session, Tor Browser makes its users look identical to one another, and Safari has narrowed the attributes available to scripts. These measures target cross-site tracking, and the browsers applying them hardest are a small share of traffic on most sites. Plan for gradual erosion of client-side entropy rather than a cliff.

The signals browsers cannot randomize are carrying more of the load. All of those measures constrain what JavaScript can read. None touches what a client reveals by the act of connecting: the shape of its TLS handshake, the order and content of its headers. A browser cannot randomize those without breaking the connection, which gives the technique a floor that browser policy is structurally unable to remove. It is the main reason fingerprinting has held up better than the countermeasure headlines suggest.

Matching has become drift-tolerant. Early implementations compared hashes for equality, which broke the moment a browser updated. Current practice scores similarity across components and maintains an identifier that persists while the fingerprint changes beneath it, so recognition survives the routine updates that used to end it. This is the substance behind the "machine learning" language common in fingerprinting marketing, and it has made fingerprints more durable in practice than raw signal decay would imply.

None of this rests on the third-party cookie deprecation that drove much of the early interest in fingerprinting. Google decided not to ship that change in April 2025 and demand did not fall away, because the value was always first-party. Expect a technique that stays dependable for recognizing returning visitors and scoring risk, leans harder on the network half as client-side entropy thins, and works best as one well-understood input into a system rather than a single identifier everything hangs from.

Implementing Browser Fingerprinting

Collecting the signals is the easy part: a client-side library reads them, hashes them and returns an identifier in a few lines of code. Everything that decides whether the deployment works sits around it.

Fingerprints drift, so a matching strategy needs a tolerance for near-matches and a plan for when an identifier changes under a returning visitor. Client-side values can be tampered with, so anything used for enforcement should reach the backend through a channel the client does not control. And because the match is probabilistic, the default should be to challenge on a mismatch rather than block outright, which keeps a false positive from becoming a lost customer.

Storage is the other decision, and it is a backend concern rather than a library one: the identifier has to be recorded somewhere durable, matched on return, and given a retention policy you can state plainly. Our guide to implementing browser fingerprinting in JavaScript works through collection, storage and matching with runnable code.

ThumbmarkJS

ThumbmarkJS is a browser fingerprinting solution that exists in two forms, and the difference between them is worth understanding before choosing one.

The open-source library is MIT licensed, runs entirely client-side and collects the browser signals described above: canvas, WebGL, audio, fonts, screen and hardware properties, permissions, plugins and locales. It hashes them into a fingerprint and gives roughly 80% uniqueness across a million visitors, enough for analytics, personalization and low-stakes deduplication, at no cost for commercial use.

The hosted API adds the server-side signals a browser cannot see: the TLS handshake signature, HTTP header analysis and connection details. Uniqueness rises to around 99%, and the response carries bot, VPN and datacenter classification, a 0 to 5 danger level, and a Visitor ID that stays stable as the underlying fingerprint drifts. These are on every API tier, including the free one, so the meaningful line is between the open-source library and the API, not between free and paid.

Getting an identifier and the classification signals takes about as much code.

// Generate a visitor identifier and read the classification signals
import { Thumbmark } from '@thumbmarkjs/thumbmarkjs';

const tm = new Thumbmark({ api_key: 'YOUR_API_KEY' });
const result = await tm.get();

console.log(result.visitorId);
console.log(result.info.classification.bot);

The documentation covers configuration options and the full response shape. For how it compares against the best-known commercial option, see our ThumbmarkJS vs FingerprintJS comparison, and for the wider field, our roundup of free fingerprinting libraries.

Conclusion

A browser fingerprint is a durable identifier for a browser environment, and knowing exactly what that covers is what makes it useful. It survives the things that break cookies, and it stops at a browser or device boundary no JavaScript technique crosses. Teams that design for that scope get a reliable recognition signal; teams that expect device-level identity get intermittent failures they cannot explain. To see what a fingerprint looks like on your own browser before writing any code, our live demo generates one in the page.