Check Your Canvas Fingerprint Hash

Check Your Canvas Fingerprint Hash Above

Run the inspector above and it generates your browser's own canvas hash the same way any tracking script would: by exploiting the HTML5 canvas element to render text and graphics, then reading back the pixel data.¹ Because rendering varies by hardware, driver, and browser, the resulting hash stays highly unique and persistent across sessions, which is what makes it effective for tracking.²

Why the hidden canvas is so stable

Drawing a hidden canvas produces a stable signal because the browser repeats the same rendering instructions each time, and the underlying hardware and software stack that executes those instructions does not change between visits. A script carefully chooses specific fonts, text strings, colors, gradients, and geometric shapes, then asks the browser to export the resulting pixel buffer through the CanvasRenderingContext2D API.²

Why hardware determines the output

Your GPU, driver, operating system compositor, and font rasterizer influence the result before the script ever hashes it, because each of these layers applies its own anti-aliasing and sub-pixel rendering decisions to the same drawing commands. Consequently, the same machine tends to produce the same canvas hash across page loads, since the rendering stack does not change between visits. This stability is what makes the technique attractive for tracking, and it explains why even two machines with the same browser version can produce different hashes when their GPU drivers differ.

You can see this stability for yourself by running the same page twice in CapyToolkit and comparing the canvas hash it reports each time. The value stays the same on a given device because the rendering stack does not change between loads, which is exactly why trackers rely on it. Changing your GPU driver or switching browsers is usually what shifts the hash, not a routine software update or a cleared cache.³

Testing the canvas hash in CapyToolkit makes this stability observable instead of abstract. The inspector reports the exact hash each run, so you can watch it stay fixed on one device and change the moment the rendering stack differs. That repeatable value is the whole reason the technique works as a tracking identifier rather than a random number.

What makes canvas different from ordinary cookies

Canvas fingerprinting does not need to store a value before it can recognize you. The script reads the rendering result immediately, hashes it, and sends that hash to its server. Because the calculation happens during the page visit, deleting site data after the fact does not prove that the signal was never collected.

Browsers cannot simply make every GPU render the same pixels without breaking graphics applications that depend on accurate color output and pixel-perfect rendering. A small change such as adding minor noise can help privacy, but a large change can distort charts, images, and games in ways that users notice immediately. That is why the best protections add controlled noise or detect suspicious hidden-canvas access rather than disabling the entire Canvas API for everyone, trading a small amount of rendering accuracy for a meaningful reduction in fingerprinting entropy.

How blocking changes the signal

Blocking canvas fingerprinting changes the signal at different depths. A browser extension can add noise to the exported pixels, which makes the hash change on each page load.⁴ Brave uses per-origin farbling so the value remains usable for the current site but does not link cleanly to another site.⁵ Firefox with privacy.resistFingerprinting can modify fingerprinting-related browser data at the engine level.⁶ Tor Browser can return a blank or null result at higher security levels.⁷ These approaches reduce uniqueness, but they also create different compatibility trade-offs. The key distinction is between noise injection, which preserves per-site functionality while preventing cross-site linking, and total blocking, which eliminates the signal entirely but can disrupt applications that depend on canvas for rendering charts, processing images, or generating data URIs.

When canvas blocking can break legitimate features

When you block canvas access completely, you may also block legitimate features that depend on the same rendering pipeline for essential functionality. Image editors, chart libraries, CAPTCHA systems, and data URI exports can all rely on canvas rendering to generate visible output or process user-submitted content.¹ A broad block can therefore create broken buttons, failed verification challenges, missing image previews, and charts that fail to render, which is why a more targeted approach is almost always preferable to a blanket API suppression.

How to target blocking more precisely

A more practical approach often targets suspicious behavior rather than blocking the entire canvas API. Scripts that create hidden canvases, export pixel data immediately after drawing, and produce no visible user-facing output are far more likely to be fingerprinting than legitimate application code. This behavioral distinction lets you reduce tracking while preserving tools that need canvas for real work such as image editors, chart libraries, and CAPTCHA systems that rely on visible canvas output.⁴ Firefox with privacy.resistFingerprinting takes a middle path by modifying the pixel buffer at the rendering engine level rather than blocking the API, which keeps canvas-dependent applications functional while still degrading the fingerprinting signal that scripts can extract.

For testing your own exposure

For testing your own exposure, compare the canvas row before and after changing browsers or settings so you can see the concrete effect of each modification. Open CapyToolkit in your default browser and record the canvas hash, then repeat the test in Brave with Shields active, Firefox with privacy.resistFingerprinting, or Tor Browser to observe how each alternative changes the output.

If the value changes, disappears, or becomes marked as blocked, the browser is reducing the canvas surface. If the value stays identical, your current setup still exposes a stable canvas fingerprint. The test turns an abstract privacy concept into a visible result you can verify. Run the same check after installing an extension or changing a browser flag, and you will see exactly which protections are active and which signals remain exposed. That concrete feedback loop is what makes the difference between assuming you are protected and knowing it.

The research history that put canvas fingerprinting on the map

Canvas fingerprinting was first documented publicly in a 2012 paper by Mowery and Shacham at UCSD, which showed that GPU-rendered canvas output varied enough across machines to serve as a passive identifier. The technique moved from academic research to widespread deployment by 2014, when EFF researchers discovered that the White House website's analytics vendor used canvas fingerprinting without disclosure, a finding that prompted regulatory attention to the practice. By 2016, the Princeton WebTAP study found canvas fingerprinting scripts on more than 14,000 of the top 100,000 websites.

The spread was rapid because the technique required no special permissions, produced no visible output, and survived all standard privacy measures of the time: cookie deletion, private browsing, and VPN use. Ad networks adopted it as a supplement to cookie-based tracking after Apple began restricting third-party cookies in Safari; fingerprinting provided continuity where cookies could no longer persist.

Despite more than a decade of awareness, canvas fingerprinting remains effective because the underlying mechanism, GPU-rendered pixel variance, cannot be eliminated without either degrading graphics functionality or accepting a clearly detectable modification. Browsers that add noise to canvas output are detectable by their inconsistency. Browsers that return blank canvases are detectable by their nullness. Only approaches that normalize output across a large user population, such as Tor Browser's shared canvas profile, genuinely reduce tracking effectiveness rather than just changing the form of the signal.

Why canvas hashes differ across browsers and operating systems

The same machine running Chrome and Firefox produces different canvas hashes because the two browsers use different 2D rendering backends. On Windows, Chrome routes canvas rendering through ANGLE (Almost Native Graphics Layer Engine), which translates OpenGL ES calls to Direct3D. Firefox uses its own Skia-based pipeline without the ANGLE translation layer. Each backend applies different anti-aliasing algorithms to curved text edges and gradient transitions, producing different pixel values for the same drawing commands.

Operating systems introduce additional variation. The macOS Core Graphics compositor applies sub-pixel font rendering rules specific to Apple's display stack. Linux systems vary depending on which font rendering library (FreeType, cairo) and which graphics stack (X11, Wayland) the browser uses. Consequently, two machines with identical CPU and GPU hardware will produce different canvas hashes if one runs Windows Chrome and the other runs macOS Safari, because the rendering stack between JavaScript and the pixel buffer differs entirely.

How rendering differences affect fingerprint stability across updates

Browser updates that change the rendering backend, upgrade the ANGLE version, or modify anti-aliasing behavior can shift canvas hashes for an entire browser generation simultaneously. When Chrome updated its ANGLE version in 2022, canvas hashes changed for a large portion of Windows users, temporarily reducing the reliability of canvas-based re-identification. Trackers that maintain long-term fingerprint databases must account for these shifts by storing multiple historical hash values per device and accepting a brief gap in recognition after major browser releases.

When to use this

Use this guide to understand why canvas fingerprinting is so effective and how blocking or randomizing canvas output reduces your tracking surface.

Examples

A script creates a hidden canvas, draws text and shapes with specific settings, then reads the pixel data to produce a hash.

The script draws "Browser Fingerprint" in 14px Arial, applies a gradient, and exports the pixel buffer. Your GPU renders it slightly differently than anyone else's, producing hash "c84efb8e...".

Websites read a consistent unique hash: c84efb8e3a92d710fbcae2f5b0078efb

With CanvasBlocker extension active, the hash changes on every page load: 7a1df3c94... then b902e8af1..., making tracking impossible.