← back to blog

Canvas fingerprinting explained: why your browser leaks even on incognito

Canvas fingerprinting explained: why your browser leaks even on incognito

Most people assume that opening an incognito window, or clearing their cookies, makes them invisible to websites. it doesn’t. there’s a class of tracking technique called browser fingerprinting, and one of its most reliable methods, canvas fingerprinting, doesn’t touch cookies at all. it reads your hardware. if you’re running any kind of multi-account operation, or just trying to understand why your accounts keep getting linked, this is the explainer you need to read first.

i run accounts across multiple platforms as part of my work. the first time i got a batch of accounts flagged despite running them through different proxies and separate sessions, i assumed the proxies were leaking. they weren’t. the problem was that every session was painting the same canvas signature. once i understood what canvas fingerprinting actually does at a technical level, a lot of other things clicked into place too.

what it is

canvas fingerprinting is a browser tracking technique that exploits the HTML5 Canvas API to generate a unique identifier for your browser and device, without storing anything on your machine. instead of setting a cookie, the tracking script asks your browser to draw something, then reads back the pixel data that results. the drawing output is slightly different for every device because of differences in GPU hardware, operating system, installed fonts, graphics drivers, and rendering settings. those differences are consistent and measurable. the result is a hash, a short string of characters that serves as a fingerprint.

the technique was formally described in a 2012 academic paper by Keaton Mowery and Hovav Shacham at UC San Diego, titled “Pixel Perfect: Fingerprinting Canvas in HTML5.” it’s been in widespread commercial use since at least 2014.

how it works

when you load a page that uses canvas fingerprinting, a small JavaScript snippet runs invisibly. here’s roughly what happens:

  1. the script creates a hidden <canvas> element that you never see
  2. it draws something onto that canvas, typically a line of text using a specific font and size, sometimes combined with geometric shapes, gradients, or emoji
  3. it calls canvas.toDataURL() or getImageData() to read the raw pixel values back out
  4. it hashes that data into a compact fingerprint string

the reason this produces a unique result comes down to how your machine renders graphics. your GPU interprets drawing instructions and applies anti-aliasing, subpixel rendering, and font hinting in ways that vary by hardware, driver version, and OS. a MacBook with an M3 chip running Safari renders the same text slightly differently than a Windows 11 machine on Chrome with an Nvidia card. those differences are tiny at the pixel level, but they’re consistent. your browser draws the same canvas the same way every single time, which makes the hash stable and reliable as an identifier.

the W3C Canvas 2D Context specification doesn’t mandate pixel-perfect consistency across implementations, which is actually what makes this attack possible. implementations are allowed to differ, and they do.

most fingerprinting scripts don’t rely on canvas alone. they combine it with dozens of other signals: WebGL renderer info, screen resolution, timezone, installed plugins, audio context fingerprint, and more. canvas is just one component in a wider fingerprint profile, but it’s one of the most stable and distinctive ones.

why it matters

it survives everything you normally do to avoid tracking. clearing cookies, using private browsing, switching browser profiles, even uninstalling and reinstalling your browser won’t change your canvas fingerprint. it’s derived from your hardware and OS configuration, neither of which changes when you open a new tab.

it’s used by legitimate platforms at scale. this isn’t just ad tech. fraud detection services like Sift, Kount, and ThreatMetrix use fingerprinting as part of their risk scoring. major platforms including Google and Meta embed fingerprinting signals into their tracking infrastructure. the EFF’s Cover Your Tracks tool lets you test your own browser and see how unique your fingerprint is against their dataset. when i ran my own browsers through it, most standard configurations came back as “unique among the browsers tested.”

for multi-account operators, it’s a direct linkage risk. if two accounts share the same canvas fingerprint, a platform’s fraud system sees them as the same device. proxies and separate email addresses don’t help if the underlying hardware signal is identical. this is one of the reasons purpose-built antidetect browsers exist, because they let you spoof or randomize the fingerprint per profile. we cover how those work in our antidetect browser guide.

it affects airdrop and DeFi farming too. on-chain activity is public, but the web frontends of most protocols still fingerprint browsers for sybil detection. if you’re farming the same protocol from ten browser profiles on the same machine, canvas fingerprinting is one of the signals that links them. the team at airdropfarming.org covers this in more depth from a farming-specific angle.

common misconceptions

“incognito mode protects me from fingerprinting.” this is the most common one. incognito mode stops your browser from saving history, cookies, and session data locally. it does not change how your GPU renders a canvas. your incognito browser still draws the same pixels as your regular browser, because it’s running on the same hardware with the same fonts and drivers. the fingerprint is identical.

“a VPN will hide my fingerprint.” a VPN masks your IP address and encrypts your traffic between your device and the VPN exit node. it has zero effect on what your browser sends when it renders a canvas element. the fingerprinting script runs locally in your browser, reads local hardware output, and sends the hash to a remote server. the VPN sees encrypted traffic but can’t change the hash that was computed before it even left your browser.

“only shady trackers do this.” canvas fingerprinting shows up in scripts loaded by major ad networks, analytics vendors, and fraud detection providers embedded across mainstream websites. if you’re shopping on a large retailer, booking travel, or logging into any platform that has invested in fraud prevention, there’s a reasonable chance a fingerprinting script has run in your session. this is a normal part of the commercial web’s identity infrastructure now, not an edge case.

“blocking JavaScript stops it.” blocking JS entirely would stop canvas fingerprinting scripts from running, but it also breaks most of the web. the practical tradeoff isn’t worth it for most people. and some fingerprinting signals, like HTTP headers and TLS fingerprinting, don’t require JavaScript at all. canvas fingerprinting specifically does require JS, but disabling JS isn’t a realistic general-purpose defense.

where to go from here

if this explainer raised more questions than it answered, here are the logical next steps:

understand the full fingerprint surface. canvas is one signal. WebGL, AudioContext, font enumeration, screen metrics, and navigator properties all contribute to your browser’s overall fingerprint. our complete browser fingerprinting guide covers all of them and explains how they combine.

learn how antidetect browsers work. tools like Multilogin, AdsPower, and Dolphin Anty are built specifically to manage fingerprint profiles. they replace your real canvas output with a spoofed or randomized value per profile. we review the main options in our antidetect browser comparison. the multiaccounting operations community at multiaccountops.com is also worth reading for operator-level discussion on fingerprint management.

test your own setup. before you invest in tooling, test what you’re currently leaking. the EFF’s Cover Your Tracks is a good starting point. browserleaks.com shows you detailed canvas and WebGL output specifically.

think about proxy and fingerprint together. a clean fingerprint without a clean IP is still a linkage risk, and vice versa. the two problems need to be solved together, not independently. our proxy selection guide goes into which proxy types pair well with fingerprint management for different use cases.

fingerprinting isn’t going away. if anything, as cookies become harder to use due to browser policy and regulation, server-side fingerprinting is becoming more common, not less. understanding the mechanism is the first step to working around it effectively.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.

need infra for this today?