What Is Device Fingerprinting and How Does It Work?

Every browser answers technical questions all day long. Which fonts can you render? What does this canvas drawing look like on your GPU? How many CPU cores do you have, what timezone are you in, what audio hardware is available? None of these answers identifies a person. Together, they describe a device precisely enough that when the same device comes back, you can tell.

That is device fingerprinting: recognizing a returning browser from its technical characteristics instead of from a cookie or a login.

The signals

Our agent collects roughly 25 signals in the browser. They fall into a few families:

• Rendering: a canvas drawing and a WebGL scene, hashed. Different GPU and driver combinations rasterize the same instructions slightly differently, and those differences are stable for a given machine.
• Hardware: CPU core count, device memory, screen geometry and pixel density, touch support.
• Environment: installed fonts, timezone, languages, platform.
• Audio: the output of a short offline audio-processing run, which varies with the audio stack.

Each signal on its own is common. Millions of devices report eight cores. But the joint combination of dozens of values is rare, and that rarity is what makes recognition possible.

From signals to an identity

A naive implementation hashes all signals into one value and calls it an id. That breaks the first time anything changes: a browser update ships a new font renderer, the user plugs in a second monitor, and the hash is different.

A production matcher works more like evidence weighing. When a device shows up, we retrieve candidate profiles the project has seen before, then compare signal by signal. Stable, high-entropy signals like canvas and WebGL hashes carry more weight; volatile ones like screen size carry less. The result is a similarity score, and a decision: this is a match, this is new, or this is genuinely ambiguous.

That tolerance for drift is the difference between a demo and something you can run in production. Browsers change constantly. An identity that survives a Chrome update is the entire point.

What it is for

We built this for one honest use case: knowing whether a device has been here before, without cookies. That single fact powers a lot of fraud prevention:

• A "new" account signing up from a device that already owns five accounts.
• A login from a device your user has never touched, right after a credential leak.
• A trial that keeps restarting itself from the same laptop.

Note what is absent: cross-site tracking. Visitor ids here are scoped to your project. The same physical device on two different customers gets two unrelated ids, so no shared profile can exist. Raw signals are deleted on a fixed retention schedule, enforced in the database.

The honest limits

Fingerprinting is probabilistic, not cryptographic. Hardened privacy browsers deliberately randomize the very signals fingerprinting reads, and against them recognition degrades, by design. Identical corporate fleets (same laptop model, same image, same fonts) compress entropy and can look alike. This is why every identification we return comes with a similarity score and a server-side verification endpoint rather than a bare yes.

Treat the fingerprint as strong evidence, combine it with your own knowledge of the account, and verify server-side before acting. Used that way, device fingerprinting quietly removes a whole class of fraud that cookies were never going to catch.