How Browser Fingerprinting Works: Canvas, WebGL, Fonts and Entropy

To use an antidetect browser sensibly you need to know what it is actually substituting. Otherwise the choice comes down to trusting marketing, and the configuration to ticking boxes at random.

Uniqueness is the combination

No single parameter identifies you. 1920×1080 is shared by millions. Windows by billions. English by hundreds of millions.

But the intersection of a dozen such traits narrows the field to one person. That is fingerprinting in a sentence: a site collects many weak signals and produces a strong one.

The value of each trait is measured in entropy - how rare it is. Browser language carries little information; the exact set of installed fonts alongside a GPU model carries a great deal.

Canvas

The best-known mechanism. A site asks the browser to render an invisible picture - text, shapes, gradients - and hashes the result.

The point is that identical code yields slightly different pixels on different hardware: font smoothing, driver version, GPU quirks. The difference is invisible to the eye but stable and easy to hash.

That durability is what makes the signal popular: it is not stored on your machine, cannot be “cleared”, and reproduces on every visit. A detailed breakdown of the mechanics is in a separate article.

WebGL

The same idea, deeper: the site reads GPU data directly - vendor, model, supported extensions - plus the result of rendering a 3D scene.

A string like “NVIDIA GeForce RTX 3060” is not unique by itself, but paired with a driver version and rendering quirks it narrows the pool sharply.

Fonts

An underrated and highly informative trait. The font set on a machine is shaped by installed software: office suites, design tools, language packs, games. Two random people rarely match.

That is why antidetect browsers manage the font list - and why the list must match the declared system. A Windows profile carrying a macOS font set contradicts itself.

Audio

Audio processing yields a fingerprint too: the browser synthesises a signal without playing it aloud and measures characteristics of the result. Differences come from the audio stack and hardware.

A weaker signal than canvas, but real, and antidetect browsers usually substitute it alongside everything else.

Screen, hardware and locale

A group of simple but mandatory parameters:

• Screen - resolution, available area, colour depth, scaling.
• Hardware - CPU core count, memory size.
• Locale - language, timezone, date format.
• Platform - OS and version as declared in the user agent.

This is where inconsistencies most often appear. Timezone is the clearest example: it comes from the system and must match the IP region. A US proxy with a Moscow timezone is a contradiction visible to a trivial check.

Behavioural signals

A separate layer that antidetect does not address at all. Platforms watch how you interact: typing speed, mouse paths, pauses between actions, navigation rhythm.

A live person types unevenly, misses buttons, gets distracted. A script does everything at identical intervals. Under automation this becomes the primary problem - the fingerprint is perfect and the rhythm is mechanical.

Why random substitution backfires

The main practical conclusion from all of the above.

It is tempting to max out randomisation: random fonts, random canvas, random resolution. The result is a profile that does not exist in nature - a GPU never shipped with that OS, a screen of non-standard size, a font set impossible on that platform.

Such a combination is rarer than any honest browser, and therefore more noticeable. A good profile is not unique but plausible and self-consistent: parameters agree with each other and correspond to configurations that really exist.

The same applies to revealing nothing. A browser that blocks canvas, hides fonts and disables WebGL is not invisible - it is a very rare and therefore memorable combination.