Canvas, WebGL, and Audio: The Three Fingerprints That Survive Every Browser Restart

Why these three, out of dozens

A modern fingerprinting script probes about 40 vectors on a typical page. User-Agent, screen size, language headers, font list, installed plugins, timezone offset, pointer precision, hardware concurrency. Most of those values are short integers or short strings, and each carries between one and five bits of entropy in practice. They are useful as glue, not as identifiers.

Canvas, WebGL, and AudioContext are different. Each one runs a deterministic workload through the device and hashes the output. The hash depends on GPU silicon, driver version, OS font rasterizer, anti-aliasing strategy, and the audio subsystem's floating-point implementation. That is why a fresh install of Chrome on the same machine still produces almost the same three hashes the next day, while the same machine with a different GPU driver produces visibly different ones.

The numbers from the EFF's Cover Your Tracks dataset and the Inria AmIUnique corpus put the canvas hash at roughly ten bits of entropy, WebGL renderer information at six to eight bits, and AudioContext at four to five bits. A session that exposes all three pushes well past eighteen bits, enough to single you out of a quarter million users, which is more than enough for ad targeting, fraud scoring, and most analytics pipelines.

Canvas fingerprinting in detail

A canvas fingerprint is the hash of a picture your browser was asked to draw and never showed you. The script creates an off-screen <canvas>, fills it with a few shapes and a string of text in two or three fonts, then calls toDataURL() and hashes the resulting PNG bytes. Nothing is visible to the user, and the entire process takes a few milliseconds.

The hash is stable on a given machine because the rendering path is deterministic. The same GPU plus the same driver plus the same OS font rasterizer plus the same anti-aliasing mode produces the same PNG, byte for byte. Change any one of those and the hash flips. That is why a Windows feature update sometimes makes a previously stable user look brand new to a tracker, and why enterprise machines with locked driver versions look almost identical to each other.

A skeleton of the attack reads like this:

const c = document.createElement("canvas");
const ctx = c.getContext("2d");
ctx.textBaseline = "alphabetic";
ctx.font = "14px 'Arial'";
ctx.fillStyle = "#069";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 2, 15);
ctx.fillStyle = "rgba(102,204,0,0.7)";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 4, 17);
const png = c.toDataURL();
// hash(png) becomes your canvas fingerprint

That snippet is not exotic. It is essentially the routine that FingerprintJS, ThreatMetrix, and Cloudflare Bot Management run on first contact, with variations. Brave and uBlock Origin defend by adding a small per-session noise function before the hash is read, which produces a different hash every time. The protection works against naive aggregators but is itself detectable: a hash that never repeats is a signal in its own right, and trackers file you under "user with canvas randomization".

WebGL fingerprinting in detail

WebGL gives the page direct access to your GPU through a JavaScript shim of the OpenGL ES API. Two things are immediately interesting. First, a tiny extension named WEBGL_debug_renderer_info exposes the GPU vendor and the rendered string verbatim, which on most desktop machines looks like ANGLE (NVIDIA, GeForce RTX 4070, OpenGL 4.5.0) or something similarly specific. That single string can carry more than ten bits of entropy on its own, because it includes the driver branch and sometimes a build hash.

Second, even when the extension is masked or disabled, the rendered output of a moderately complex 3D scene (a textured torus, a gradient sphere, a few rotated triangles) is still hashable. Different shader compilers, different precision settings, and different blending implementations move pixels by small but consistent amounts. The script reads back the framebuffer with readPixels(), hashes it, and stores the result.

Disabling WebGL outright is the cleanest defense and the most expensive. Google Maps, most browser games, half of the modern SaaS tools that render charts on the GPU, and a surprising number of e-commerce 3D viewers stop working. Firefox exposes a webgl.disabled preference for users who accept that trade. Tor Browser leaves WebGL enabled but normalizes the renderer string to a uniform value across all installs, which is why two Tor users on completely different hardware report the same WebGL signature to the page.

AudioContext fingerprinting in detail

AudioContext fingerprinting is the quietest of the three, in every sense. The script instantiates an OfflineAudioContext, generates a triangle or sine wave at a fixed frequency, runs it through a dynamics compressor with set parameters, and reads the resulting samples back as a Float32Array. No sound ever reaches the speakers. The device does not need to be unmuted. Headphones do not matter. What matters is the floating-point math your audio stack used to produce those samples.

Audio output looks identical to a human (and to any spectrum analyzer that cares about audible content), but the underlying float32 values differ between implementations of the compressor algorithm. Browser builds, OS audio engines, and even some CPU microcode revisions push the least-significant bits around in stable patterns. Hashing the buffer or summing it produces a number that survives reboot, profile reset, and most extensions.

AudioContext carries less entropy than canvas (typically four to five bits), so on its own it does not single anyone out. Its real value to a tracker is that almost nobody defends it. Canvas and WebGL get noisy attention from privacy tooling, but audio sits underneath. A script that finds matching canvas and audio hashes across two sessions is more confident in the match than canvas alone would justify, because the audio number is unlikely to repeat by accident.

How the three compare

Side by side, the three vectors have different strengths. The table below summarizes what each one buys a tracker, what it costs you to defend, and how visible the defense itself is to the tracker.

The pattern is consistent. Each vector is hard to defeat in isolation, and the defenses that work are conspicuous. A tracker that sees normal canvas plus normal WebGL plus a missing AudioContext flag is looking at a small slice of the population, and that itself is identifying.

Why Tor still leaks one of them

Tor Browser is the most aggressive consumer-grade defense against static fingerprinting. By default, canvas reads return a uniform white image (the user is prompted before any real data is released). WebGL is enabled but the renderer string is normalized to a single value across every Tor install on the same platform, and the rendered output is rounded to remove driver variance. Two of the three vectors are effectively dead inside Tor.

AudioContext is the loose thread. Tor Project's threat model covers it (ticket tor-browser#13017 and related Mozilla bug reports go back years), but the floating-point output of an OfflineAudioContext still depends on the build chain. A Tor Browser running on Linux x86_64 against a Tor Browser running on macOS arm64 produces measurably different audio hashes, even when both report the same platform string. Researchers have published working AudioContext distinguishers for Tor several times, including in the original AmIUnique work and more recent academic follow-ups.

The remediation is hard because the alternative is to disable OfflineAudioContext entirely, which breaks every web app that decodes audio in the background (podcast players, video conferencing, browser games, accessibility tools). The Tor Project has stayed conservative on that change. The result is that even the most carefully hardened consumer browser still exposes one of the three.

What actually defeats these

The three vectors share a property: they are all derived from physical hardware behavior. Software-only defenses help, but the only complete answers change what the page sees from your machine, not what your machine actually is.

FAQ

Where this leaves you

Canvas, WebGL, and AudioContext together push past eighteen bits of entropy in a single session. That is enough to pick one user out of more than 250,000, and every tool aimed at the cookie era (incognito, VPNs, most privacy extensions) leaves all three untouched. The hashes come out of your GPU, your drivers, your fonts, and your audio stack, and that is exactly the layer those tools never reach.

Defending one vector at a time is itself visible. Canvas randomization, WebGL masking, and audio noise all produce detectable anomalies, so trackers can bucket "defended" users into a smaller and arguably more interesting group. Tor closes two of the three convincingly and still leaks the audio signature. The only fix that closes all three is to change the hardware and software stack the page is allowed to see, which in practice means a different physical machine, a different OS install, or a remote containerized browser like Browser.lol.