Canvas, WebGL, and Audio Fingerprinting Explained

TL;DR: Canvas, WebGL, and audio fingerprinting derive a stable device identifier from the way hardware renders graphics and processes sound, without storing anything in the browser. Because there is no cookie to block or delete, consent banners never touch it. Detection works by instrumenting a browser and logging which scripts call the fingerprinting APIs and what they read back.

Cookie-based tracking has an off switch. Users can clear cookies, browsers can partition them, and consent banners can gate them. Fingerprinting was engineered not to have an off switch: instead of storing an identifier on the device, it computes one from the device itself. Three browser APIs do most of the heavy lifting, and none of them were designed for tracking at all.

What makes a fingerprint different from a cookie?

A cookie is state: a value written to the browser that can be read back later. A fingerprint is a measurement: a set of device characteristics combined and hashed into an identifier. The distinction has practical consequences. Clearing cookies, opening a private window, or switching sessions does not change your GPU, your installed fonts, or your audio hardware, so the fingerprint stays constant. And because nothing is written, there is nothing for a cookie control to block or delete.

Fingerprints are probabilistic rather than exact. Each measured trait contributes entropy, bits of identifying information, and each additional bit halves the size of the crowd a device blends into. Roughly 33 bits of entropy is enough, in principle, to single out one device among billions. No single API gets there alone, which is why fingerprinting scripts stack techniques.

How does canvas fingerprinting work?

The HTML canvas element lets a script draw shapes and text, then read the result back as pixel data through toDataURL or toBlob. Fingerprinting scripts exploit the fact that the "same" drawing is not rendered identically everywhere. Anti-aliasing choices, sub-pixel font rendering, GPU drivers, and the operating system's text stack all introduce tiny but consistent differences. The script draws a hidden test image, often a string of mixed characters and emoji layered over shapes and gradients, reads the pixels back, and hashes them. The hash is stable for a given device and different across devices, which is exactly what a tracking identifier needs.

A close cousin is canvas font fingerprinting. Instead of reading pixels, the script measures the rendered width and height of a test string across a long list of font families. Installed fonts render with their own metrics, while missing ones fall back to defaults. The resulting installed-font inventory is a high-entropy signal on its own, because font sets vary with operating system, language settings, and installed software.

How does WebGL fingerprinting reveal your GPU?

WebGL exposes the graphics stack to JavaScript, and with it, identity. A script calls getParameter to request the renderer and vendor strings, and through the debug renderer extension it can obtain the unmasked GPU model and driver identity. A string naming your exact graphics hardware is inherently identifying: it is stable across sites and sessions, and it narrows a visitor from billions of browsers down to owners of one hardware configuration.

WebGL also supports a render-and-read variant similar to canvas fingerprinting: draw a 3D scene, read back the pixels, and hash the result. That captures driver-level rendering differences the identity strings alone do not expose, and it stacks with them.

How can audio identify a device without playing a sound?

Audio fingerprinting uses the Web Audio API's OfflineAudioContext, which processes audio in memory without ever reaching the speakers. The canonical technique creates an oscillator, routes it through a processing node such as a compressor, renders the signal offline, and samples the output buffer. Floating-point behavior in the audio stack differs subtly across hardware, operating systems, and browser builds, so the sampled values hash into yet another stable identifier. The visitor hears nothing and sees nothing, and the whole operation takes a fraction of a second.

Why does fingerprinting bypass cookie consent?

Consent tooling is built around storage. It blocks cookies, gates tags until a choice is made, and deletes identifiers on request. Fingerprinting sits below that entire model. The APIs involved are legitimate and used constantly by games, charts, and media players, so browsers cannot simply remove them, and a banner that gates cookies does nothing about a script that computes an identifier from rendering behavior.

Legally, this is not a loophole. European regulators treat fingerprinting as tracking that requires consent just like cookies, because ePrivacy rules cover any access to information on a user's device, not only stored identifiers. But practically, a site can be fully "cookie compliant" while identifying every visitor who rejects tracking. This is one of the clearest cases where privacy scanning has to observe behavior rather than check declarations.

How is fingerprinting detected from the outside?

You cannot detect fingerprinting by reading a page's HTML, because the technique lives in JavaScript behavior at runtime. Detection works by loading the page in an instrumented browser where the relevant APIs are patched before any page script runs. When a script reads canvas pixels, requests GPU identity parameters, or drives the offline audio rendering chain, the instrumentation logs the call, the values involved, and the exact script URL responsible.

Attribution and thresholds matter, because the same APIs have honest uses. A charting library reading back a canvas it just drew for export is not tracking. Signals that separate fingerprinting from legitimate use include:

• Reading pixels from a canvas the user never sees.
• Requesting GPU identity strings rather than capability limits a renderer would actually need.
• Running the oscillator-to-offline-render chain with no audible output path.
• Loading from domains associated with commercial device-intelligence services.

Combined with the entropy of the properties a page actually queried (screen metrics, hardware concurrency, device memory, and similar), this produces findings backed by evidence: which script, which API, and what it read. That evidence-first standard is described in OnScanner's methodology.

Which technique leaks which signal?

What should site owners do about it?

First, know whether it is happening on your site at all. Fingerprinting usually arrives through third-party scripts: an ad partner, an anti-fraud SDK, an embedded widget. Few site owners add it deliberately, and fewer disclose it. Scanning your own site with an instrumented browser, as part of a full privacy and tracker analysis, tells you which scripts are fingerprinting your visitors before a regulator, a journalist, or a user with developer tools tells you first.

If the source turns out to be a vendor SDK, the decision becomes contractual rather than technical: require disclosure, configuration that disables the behavior, or removal. Either way, the starting point is the same evidence a scan provides, down to the script URL and the API calls it made.

Frequently asked questions

Is browser fingerprinting illegal?

Fingerprinting is a technique, not an offense in itself, but in jurisdictions with GDPR-style rules it is treated as processing that requires a lawful basis, and ePrivacy rules extend consent requirements to any access to information on a user's device. Fingerprinting deployed for cross-site tracking without informed consent carries the same legal exposure as setting tracking cookies without consent, and it is harder to defend because it is covert.

Can visitors block fingerprinting themselves?

Only partially. Some browsers randomize canvas readbacks, coarsen measurements, or restrict known fingerprinting scripts, and extensions can block device-intelligence SDKs from loading. But the underlying APIs are needed by legitimate applications, so they cannot be disabled wholesale without breaking sites. Blocking also creates a paradox: an unusual protection profile can itself become an identifying signal. Removing fingerprinting at the site is far more effective than defending at the visitor.

Does OnScanner detect fingerprinting on my site?

Yes. OnScanner loads your pages in an instrumented browser and monitors the canvas, WebGL, and audio APIs, along with known commercial fingerprinting SDK domains, as part of its privacy analysis across more than 40 tracker and privacy categories. Findings identify the responsible script and the evidence observed, and every scan runs live against your site, with nothing served from a cache.