What is browser fingerprinting?

Browser fingerprinting is a technique that identifies a specific browser installation by combining dozens of attributes the browser exposes, such as canvas rendering output, WebGL renderer details, installed fonts, and screen metrics, into a single identifier. It works without cookies or any stored state, so it survives cleared storage, private windows, and logged-out sessions. The fingerprint identifies a browser install, not a person.

How it works

A script reads attributes that vary from one machine to the next. Canvas fingerprinting draws text and shapes onto a hidden canvas element and hashes the pixel output; GPU hardware, graphics drivers, and OS font smoothing each nudge the pixels enough to separate machines. WebGL contributes the reported vendor and renderer strings plus its own rendered output. Audio context fingerprinting pushes a generated signal through an oscillator and compressor and hashes what comes out. Font detection measures rendered text against a list of known typefaces to infer what is installed. On top of that sit screen resolution, device pixel ratio, color depth, timezone, languages, and User-Agent Client Hints, the structured values Chromium browsers now offer in place of the old User-Agent string.

Each attribute contributes some entropy, and together they narrow a browser down fast. Peter Eckersley's 2010 EFF study found at least 18 bits of entropy in the fingerprint distribution, and 84% of sampled browsers were unique among roughly 470,000 participants. The catch is that the highest entropy signals are also the least stable. A browser update can change canvas output overnight, a driver update rewrites the WebGL renderer string, and a new monitor changes screen metrics. Production systems expect this drift: they match fingerprints fuzzily and let an identifier evolve over time instead of comparing exact hashes.

Browser vendors also push back. Safari deliberately exposes a small surface (system fonts only, a simplified User-Agent) as part of WebKit's tracking prevention work. Firefox ships a fingerprinting protection mode that reports generic values for timezone, screen size, and other attributes. Brave randomizes canvas and audio readouts per site. The practical effect is lower entropy in those browsers: thousands of Safari users on the same iPhone model and iOS version can produce nearly identical fingerprints.

That is why the per-browser frame matters. Chrome and Safari on the same laptop produce two unrelated fingerprints, so one person can look like three "users" across the browsers they use. Fingerprinting gives you continuity within a single browser install. Person-level continuity, recognizing the same actor across browsers and devices, needs an identification layer on top: account linkage, device fingerprinting, IP history, and behavioral signals.

How to detect it

For fraud teams the operational question is usually the reverse: detecting browsers that lie about their fingerprint. The reliable signals are contradictions between attributes.

• A User-Agent that claims Windows while WebGL reports an Apple GPU, or a claimed iPhone with a screen size no iPhone ships.
• A desktop browser with touch events, or a mobile browser with none.
• Timezone and language that never line up with the IP address's region.
• Canvas output that changes between two identical draws in the same session, which means noise injection by Brave or an anti-detect browser.
• Automation artifacts: navigator.webdriver set to true, missing codec and plugin sets, or a software renderer like SwiftShader on a machine that claims a gaming GPU. These overlap heavily with bot detection.

Some checks only work across a whole population of sessions. A fingerprint shared by thousands of "different" accounts points at an anti-detect template, a pattern common in multiaccounting and ban evasion. Anti-detect browsers spoof attributes one at a time, and the seams between attributes are where they get caught.

How Rupt handles it

Rupt collects canvas, WebGL, audio, font, and client hint signals with consistency checks built in, and treats the resulting browser fingerprint as one input rather than the whole answer. Its identification layer links fingerprints to devices and accounts, so recognition survives fingerprint drift and works across the browsers one person actually uses.