FG Media's blog : Canvas Fingerprinting Explained: How Websites Identify Your Device

Delete your cookies, open a private window, connect through a VPN — and many websites will still recognize your machine within a second of the page loading. The mechanism behind this is canvas fingerprinting: a script asks your browser to draw a hidden image, reads the resulting pixels, and hashes them into an identifier tied to your hardware and software stack. The same drawing commands produce measurably different pixels on different machines, and that difference is stable enough to track you. An entire market of countermeasures has grown around it, from Tor Browser's canvas blocking to every commercial antidetect browser, all built on the same insight: if rendering output identifies the device, you must either block the reading or replace the output. This article explains how the identification works at the pixel level, how unique and stable the resulting fingerprint is, who relies on it, and where each defense breaks down.

What Canvas Fingerprinting Is

Canvas fingerprinting uses the HTML5 <canvas> element as a measurement instrument rather than a drawing surface. A script creates an invisible canvas, renders text and shapes onto it, exports the pixel data, and computes a hash. That hash — a short hex string such as 6dd2ff3a — becomes one component of a device fingerprint. The technique was described in academic research in 2012, and by mid-2014 crawls of the top 100,000 websites found it running on more than 5,000 of them, largely because a single social-sharing widget had embedded it silently. Unlike a cookie, the identifier is never stored on your device. There is nothing to delete. The website recomputes it on every visit, and your machine keeps producing the same answer.

How the Canvas API Actually Renders

The 2D canvas context exposes drawing primitives: fillText() for text, arc() for curves, gradients, shadows via shadowBlur, and blending modes through globalCompositeOperation. When a script calls these, the browser hands the work to its graphics engine — Skia in Chrome and Edge, Core Graphics in Safari, Skia in current Firefox. Text goes through a shaping engine (HarfBuzz in most browsers) and then to the operating system's font rasterizer: DirectWrite on Windows, Core Text on macOS, FreeType on Linux. Each rasterizer makes its own decisions about anti-aliasing, glyph hinting, subpixel positioning, and gamma correction. Windows ClearType, for example, tints glyph edges with red and blue subpixels; macOS abandoned subpixel smoothing in Mojave and renders grayscale.

The WebGL Path

WebGL adds a second, richer surface. Chrome and Firefox on Windows translate WebGL calls to Direct3D through the ANGLE layer; on macOS the target is Metal, on Linux OpenGL or Vulkan. GPU shader precision, driver-specific rounding of floating-point operations, and texture filtering all leave marks in the rendered output. On top of that, the WEBGL_debug_renderer_info extension hands over the GPU identity in plain text — a string like ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 Direct3D11 vs_5_0 ps_5_0). No pixel analysis needed for that part; the browser volunteers it.

Why Identical Code Produces Different Pixels

Every layer between the JavaScript call and the framebuffer introduces variation. A one-pixel difference in anti-aliasing changes the exported hash completely, so even tiny divergences separate devices cleanly.

Variation source	Concrete example	What it reflects
GPU and driver	RTX 3060 on driver 551.86 vs 546.33 rounds shader math differently	Hardware model, driver version
OS font rasterizer	DirectWrite hinting vs Core Text grayscale smoothing	Operating system and its updates
Browser engine	Skia version bundled with Chrome 126 vs 127	Browser and exact build
Installed fonts	Fallback chain picks Segoe UI vs Liberation Sans for the same CSS	Locale, installed software
Emoji set	😃 drawn from Segoe UI Emoji, Apple Color Emoji, or Noto Color Emoji	Platform and OS version
User settings	ClearType tuned, font smoothing disabled, forced dark mode	Individual configuration

Emoji are a favorite probe precisely because vendors redraw them constantly. Apple reworked dozens of glyphs between iOS versions; a single Windows feature update swaps the Segoe UI Emoji file. Scripts that include an emoji in their test string capture OS version granularity that a user agent string can lie about.

From Pixels to an Identifier

Two APIs export the drawing. toDataURL("image/png") returns the canvas as a base64-encoded PNG string; getImageData() returns the raw RGBA byte array. Either output feeds a hash function — MurmurHash3 in the widely used open-source FingerprintJS library, SHA-256 in stricter implementations — producing a fixed-length token. That token alone is rarely the whole fingerprint. Servers combine it with the WebGL renderer string, an AudioContext hash (the same trick applied to sound processing), screen dimensions, timezone, installed font measurements, and hardware concurrency, then hash the bundle again into one composite visitor ID. The canvas component contributes several bits of entropy to that composite, and among passive signals it ranks near the top for discriminating power.

A Tracking Script, Step by Step

Here is what a fingerprinting script on a typical e-commerce login page does, in order:

Creates a canvas element 280×60 pixels, never attaches it to the DOM — the user sees nothing.
Sets the font to 14px Arial and writes a probe string containing mixed-case Latin text, digits, and an emoji, e.g. Cwm fjordbank glyphs vext quiz 😃, twice, with a slight offset and different fill colors.
Draws a semi-transparent rectangle over the text with globalCompositeOperation = "multiply", forcing blending math that varies by engine.
Adds an arc with shadowBlur = 8, exercising the shadow rasterizer.
Calls toDataURL() and hashes the result with MurmurHash3 — total execution time under 30 ms.
Requests a WebGL context, reads UNMASKED_RENDERER_WEBGL, and hashes a small rendered 3D scene the same way.
Bundles both hashes with roughly 20 other attributes into a JSON payload and POSTs it to the fingerprinting endpoint.
The server matches the composite against its database. A returning device gets its existing visitor ID back — linking this session to visits made months ago under cleared cookies, a different IP, and private browsing.

Nothing in this sequence triggers a permission prompt in Chrome. The page paints normally, and the user has no visible indication that measurement occurred.

How Unique and How Stable

Large-scale measurements of browser populations show the canvas hash alone splits visitors into thousands of distinct groups, and the composite fingerprint is unique for the majority of desktop browsers — figures around 80–90% recur across studies. Mobile is a different story. Every iPhone 15 running the same iOS build with the same Safari version renders identical pixels, so canvas hashes collide en masse on iOS; trackers there lean harder on other signals.

Stability cuts both ways. The fingerprint survives everything a privacy-conscious user typically does: clearing site data, incognito mode, switching networks, reinstalling the browser. It breaks when the underlying stack changes — a Chrome major update, a GPU driver update, an OS upgrade that swaps the emoji font. Commercial fingerprinting services handle this drift with fuzzy matching: if 18 of 20 attributes still align and only the canvas hash moved, the server links the new fingerprint to the old identity and updates the record. Tracking continuity survives the change; only a full hardware replacement reliably resets it.

Who Uses Canvas Fingerprinting and Why

Advertising networks were the first large-scale adopters, using fingerprints to respawn deleted cookies and stitch together cross-site profiles. Regulators pushed back — under GDPR and the ePrivacy rules, fingerprinting requires the same consent as cookies — and overt ad-tech use declined, though enforcement remains thin.

The technique now dominates in security contexts. Banks compare the fingerprint at login against the device history on the account; a session that starts on a known laptop and continues from an unrecognized machine mid-transaction gets flagged for account takeover. Bot-detection vendors rely on it because headless Chrome betrays itself: rendering through the SwiftShader software rasterizer produces a canvas output and renderer string that no consumer GPU generates. Marketplaces, betting operators, and sneaker retailers use fingerprint collisions to detect multi-accounting — fifty "different" customers whose devices render identical canvases are one person with fifty logins. Paywalled news sites count article views per fingerprint rather than per cookie.

Defenses and Their Trade-offs

What Browsers Do by Default

Browser	Approach	Trade-off
Tor Browser	Blocks canvas reads; site gets a blank white image unless the user grants permission	Maximum protection, but the blocking itself marks you as a Tor user
Firefox (resistFingerprinting enabled)	Permission prompt on canvas extraction; uniform values for other attributes	Off by default; breaks some sites; must be enabled in about:config
Brave	"Farbling" — deterministic noise, unique per site and per session, seeded so the same site sees consistent values within a session	Strong default; occasional breakage in canvas-heavy web apps
Safari (private browsing)	Injects noise into canvas and other fingerprinting surfaces in recent versions	Applies fully only in private windows
Chrome / Edge	No built-in canvas protection	Full fingerprint exposed by default

Randomization, Blocking, and Spoofing

Extensions such as CanvasBlocker add noise to every canvas read, and this is where the arms race gets interesting: randomization is itself detectable. A script can draw the same image twice and compare hashes — a real device returns identical output, a randomizer returns two different ones. It can also render a known test image whose correct hash for a given engine is documented; a mismatch reveals tampering. Fraud-detection systems treat detected noise as a stronger risk signal than any particular fingerprint, because honest consumer browsers do not randomize. Being unrecognizable every visit is its own kind of recognizable.

That paradox explains the opposite strategy: instead of scrambling the fingerprint, replace it wholesale with a consistent, plausible profile of a real device — a coherent set of canvas output, WebGL renderer, fonts, and screen metrics that match an actual hardware configuration. This is the approach antidetect tooling takes, and it works precisely because consistency, not randomness, is what verification systems test for.

Practical measures, in rough order of effectiveness for an ordinary user:

Use Brave or Tor Browser if fingerprinting resistance matters to you; their protections ship enabled and are maintained against detection techniques.
Avoid stacking multiple anti-fingerprinting extensions — their combined noise patterns are easier to detect than either alone, and they can conflict.
Check your own exposure on test pages such as AmIUnique or CreepJS, which show your canvas hash and how rare it is.
Accept that VPNs and cookie cleaning do nothing here; they address different tracking layers entirely.

Edge Cases Worth Knowing

OffscreenCanvas lets worker threads render without a DOM element, and early canvas-blocking extensions missed it entirely — a reminder that the API surface keeps growing. Farbling and noise injection break legitimate applications that read pixels for real purposes: browser-based photo editors, canvas-rendered games, and signature-capture widgets can malfunction under randomization. Enterprise fleets deployed from a single VM image produce identical fingerprints across hundreds of machines, which makes them useless for individual tracking but instantly suspicious to fraud systems tuned to expect diversity. And on iOS, where every browser must use WebKit, canvas variation between "different" browsers on the same phone is close to zero — the fingerprint identifies the device model and OS version, not the app.

FAQs

Is canvas fingerprinting legal?

In the EU, fingerprinting falls under the same consent requirements as cookies: ePrivacy rules cover any access to information on a user's device, and regulators have stated this includes fingerprinting scripts. In practice, enforcement against fingerprinting specifically has been rare, and security and fraud-prevention uses often proceed under legitimate-interest claims. In the US there is no federal prohibition; state privacy laws in California and Colorado treat persistent identifiers as personal data, which imposes disclosure duties rather than a ban.

Does incognito or private mode stop it?

No. Private mode discards cookies and history when the window closes, but the canvas render depends on your hardware, drivers, fonts, and browser build — none of which change in incognito. Your private-mode fingerprint matches your normal one, which is exactly how sites link the two sessions. Safari's private browsing is a partial exception because it injects noise into fingerprinting surfaces.

Can two different computers produce the same canvas fingerprint?

Yes, when their stacks are identical: same device model, same OS build, same browser version, same fonts. This is common on iPhones and on corporate machines cloned from one image. Trackers resolve such collisions using the rest of the composite fingerprint — IP ranges, timezone, screen metrics — or accept the ambiguity.

Does a VPN protect me from canvas fingerprinting?

No. A VPN changes your IP address and encrypts traffic in transit. The fingerprint is computed by JavaScript running inside your browser and describes your machine, not your network path. Sites that combine both signals will simply record that a known device appeared from a new IP.

How much of my fingerprint is the canvas versus everything else?

The canvas hash typically contributes several bits of entropy — enough to split the population into thousands of groups but not to identify you alone. Uniqueness comes from combination: canvas plus the WebGL renderer string, audio fingerprint, font list, screen resolution, timezone, and language settings together identify most desktop browsers uniquely. Remove the canvas component and the composite loses one of its strongest attributes, but tracking usually still succeeds.

Why don't browsers just remove the pixel-reading APIs?

Because legitimate features depend on them. Photo editors export edited images through toDataURL, games read pixels for collision detection and screenshots, charting libraries render to canvas and let users download the result. Removing read access would break a large slice of the web platform, so browser vendors instead ration it: prompts in Tor and Firefox, noise in Brave and Safari, and — so far — nothing in Chrome.

Conclusion

Canvas fingerprinting works because rendering is honest. Your GPU, driver, font stack, and browser build cannot help but leave their signature in the pixels they produce, and a 30-millisecond script converts that signature into an identifier that outlives every cookie you delete. The technique has migrated from covert ad tracking toward fraud and bot detection, where its persistence is a feature users indirectly benefit from — and a liability for anyone who wants to move through the web unrecognized. Defenses exist at every level, but each carries a cost: blocking marks you, randomizing exposes itself, and spoofing demands internal consistency that is hard to fake. Which trade-off is right depends on your threat model. Knowing that the trade-off exists, and that a hidden 280×60 drawing is deciding it, is the necessary first step.

In: