Watch your browser draw a live canvas, then see the exact SHA-256 hash and
entropy it produces — one signal out of the 14 measured by our
full Browser Fingerprint Test,
isolated here so you can test it, and your protection against it, on its own.
Canvas renderer
320×120 canvas, rendered live in your browser
Live, real GPU render
Click Run Test to draw
Nothing is sent anywhere — this draw happens entirely on your device
SHA-256 hash of the rendered canvas
Click Run Test…
Trackability
--
Render time
--
Canvas entropy sourced from the same published methodology as the full test. View methodology
What different browsers typically produce
Same browser, two reloads
Chrome vs. Firefox
Brave or Tor Browser
…
Identical
Usually differs
Randomized / blocked
a3f9e1c2…7bc204 = a3f9e1c2…7bc204
a3f9e1c2…7bc204 vs a3f9e1c2…d92a58
Different every visit, or permission prompt first
Deterministic rendering means the same GPU and OS produce identical pixels and hash every time, unless anti-fingerprinting randomization is active.
Different engines apply subtly different anti-aliasing, changing the hash even on identical hardware.
Brave adds per-session noise by default; Tor blocks the read until explicitly allowed.
How a canvas fingerprint is built
01
Site requests a canvas
A page creates a hidden or visible <canvas> element — no permission prompt required in most browsers.
02
Hidden text is drawn
Specific text, shapes, and a gradient are drawn using fonts and colors chosen to maximize rendering differences.
03
Pixels are read back
The script calls toDataURL() or getImageData() to pull the exact rendered pixels out of the canvas.
04
Pixels become a hash
The raw pixel data is hashed (commonly SHA-256, as this tool does) into one short, stable string.
05
Hash becomes an ID
That hash is stored and treated as a device identifier — stable across sessions unless your browser blocks the read.
Survives cookie clearing
Rebuilt fresh from your hardware and OS on every visit — clearing cookies or storage has no effect on it.
No permission needed by default
Chrome, Firefox, and Safari all allow canvas reads silently out of the box — no popup asks your consent.
~15 bits of entropy alone
A single high-entropy signal — enough on its own to narrow you down among a large share of the internet's visitors.
How major browsers handle canvas reads, by default
Chrome / EdgeNot blocked
Canvas reads are allowed silently; no built-in protection without an extension.
Firefox (default)Not blocked
Standard Enhanced Tracking Protection doesn't cover canvas reads by default.
Enabling privacy.resistFingerprinting in about:config prompts before canvas reads.
SafariPartial
Intelligent Tracking Prevention limits some cross-site use, but same-site canvas reads are largely permitted.
Brave (default)Randomized
Shields adds imperceptible per-session noise to canvas output automatically.
Tor BrowserBlocked
Prompts before any site can read canvas pixel data; denying keeps the canvas blank.
Canvas fingerprinting edge cases most guides skip
Cloud VMs can share a hash with strangers
Virtual machines spun up from the same base image — common on cloud desktops, CI runners, and
some corporate remote-desktop fleets — often share an identical virtual GPU, OS build, and font
set. Two completely unrelated people on freshly provisioned identical VMs can genuinely produce
the same canvas hash, which is one of the rare real-world canvas fingerprint collisions.
An OS or driver update can silently change your hash
Because canvas output depends on your graphics driver and OS font-rendering pipeline, a routine
GPU driver update or OS font hinting change can shift your canvas hash even though nothing about
your identity changed. Trackers that rely on canvas hash alone occasionally lose continuity on
users this way — one reason real fingerprinting systems combine it with other, more stable signals.
Mobile browsers are more uniform, not immune
iPhones running the same iOS version render canvas output far more uniformly than the desktop
GPU/driver landscape, which lowers canvas entropy specifically on mobile Safari. This doesn't
make mobile safe from fingerprinting overall — sites compensate by leaning harder on other
signals — it just means canvas contributes less identifying power on a phone than on a desktop.
A privacy extension can break the test itself
Some canvas-blocking extensions return a blank white canvas instead of prompting, which this
tool correctly reports as a low-entropy "protected" result — but a few older or misconfigured
extensions throw a JavaScript error instead of returning blank data, which can make the test
fail to complete rather than report a protected result. If Run Test seems stuck, try disabling
canvas-related extensions one at a time to isolate which one is intercepting the call.
How to reduce canvas fingerprinting
Use Brave browser
Brave randomizes canvas output per session by default — zero configuration needed.
Best protection
Install CanvasBlocker (Firefox)
A dedicated extension that fakes canvas, WebGL, and audio output with configurable, per-site randomization.
Strong protection
Enable resistFingerprinting
In Firefox, set privacy.resistFingerprinting to true in about:config to prompt before any canvas read.
Strong protection
Use Tor Browser
Blocks canvas reads by default across every site — maximum protection, at a real cost to browsing speed.
“What exactly does this test measure, versus the full Browser Fingerprint Test?”
This page isolates just one of the 14 signals used by our full Browser Fingerprint Test: the canvas hash. It draws real shapes, gradients, and text to a visible <canvas> element, reads the pixel data back with toDataURL(), and hashes it — exactly what a tracking script does, minus the tracking. The full test combines this signal with WebGL, fonts, audio, and 10 others into one overall uniqueness score; this page exists to let you see the canvas signal on its own, since it's consistently one of the highest-entropy individual signals.
“Why does my canvas hash stay identical every time I reload, on a normal browser?”
Canvas rendering is deterministic. Given the same GPU, graphics drivers, operating system font-rendering pipeline, and anti-aliasing settings, drawing the exact same shapes and text produces the exact same pixels — and the exact same pixels always hash to the exact same SHA-256 value. A stable hash on repeated tests isn't a bug; it's the mechanism working as intended, which is also exactly why it's useful for tracking. A hash that changes between reloads is the unusual case — see the next question.
“Does the "Save image" button upload my canvas anywhere?”
No. The button calls canvas.toDataURL() to get the PNG as a base64 string already sitting in your browser's memory, wraps it in a download link, and triggers a local file save — the same mechanism any "save as" button uses. No network request is made and nothing leaves your device. You can verify this yourself by opening your browser's Network tab before clicking Save; there will be no new request logged.
“Why did my browser show a permission prompt instead of just running the test?”
Tor Browser, and some hardened Firefox configurations with privacy.resistFingerprinting enabled, intentionally ask before letting any page read canvas pixel data back — because the read, not the draw, is what makes canvas fingerprinting possible. If you see a prompt, that's the browser's canvas protection working correctly; denying it (or ignoring it) is itself a safe outcome and this tool will report it as a blocked canvas.
“Is the SHA-256 hash shown here reversible back into an image?”
No — SHA-256 is a one-way cryptographic hash; there is no mathematical way to reconstruct the original canvas pixels from the 64-character hash alone. That said, this doesn't make canvas fingerprinting harmless: a real tracking script typically stores the hash itself as your identifier, exactly like this tool displays, since re-drawing the same canvas on your next visit reproduces the same hash without ever needing to "reverse" anything.
“Does clearing cookies or using Incognito mode change my canvas hash?”
No. Cookies and private browsing operate at a completely different layer than canvas rendering. Your GPU, OS, and font-rendering pipeline don't change when you clear storage or open a private window, so the same canvas draw produces the same hash regardless. This is precisely what makes canvas fingerprinting attractive to trackers: it survives the exact privacy actions most people assume reset their identity.
“Can two different computers produce the same canvas hash?”
It's rare but not impossible. Canvas output depends on GPU model, driver version, operating system, and installed font-rendering settings — machines that share all of those (identical cloud VM images, or two devices with the exact same hardware/software configuration fresh from the factory) can genuinely produce matching hashes. In practice, the combination of variables involved makes collisions uncommon enough that canvas hash is still treated as a high-entropy signal in fingerprinting research, contributing roughly 15 bits of entropy on its own.
“How is this different from WebGL fingerprinting?”
They're closely related but not the same signal. Canvas fingerprinting (measured here) reads back 2D pixel output from text and shapes drawn with the Canvas API. WebGL fingerprinting instead reads GPU-reported strings like the renderer and vendor name through the 3D rendering context, and can also render 3D scenes for a separate pixel-based hash. Both end up correlated with your specific graphics hardware, which is why the full Browser Fingerprint Test measures them as two distinct signals rather than one.
Community
Get the next leak test before it's news
Tool releases and research notes, sent when there's something worth reading. Nothing else.
