Canvas, audio, and font signals in device identification

The problem with just rotating an IP

Anyone who has run a proxy farm long enough learns this the hard way: swapping the IP address in front of a request doesn’t make the request anonymous. The site on the other end isn’t just looking at where the traffic came from. It’s looking at what rendered the page, what generated the audio buffer, and which fonts got measured during layout. Those three signals, canvas, audio, and fonts, are some of the oldest and still most widely deployed pieces of browser fingerprinting. This is a look at how each one actually works under the hood, not a guide to getting around them.

What a canvas fingerprint actually measures

Canvas fingerprinting uses the HTML5 <canvas> element, which was built for drawing graphics in the browser, as a side channel for hardware and software identification. A script draws some combination of text, shapes, and gradients onto an off-screen canvas, then calls toDataURL() or getImageData() to read back the raw pixel data.

The trick is that the same drawing instructions don’t produce identical pixels across machines. Anti-aliasing, sub-pixel rendering, font hinting, and GPU-level rasterization all vary by operating system, graphics driver, and even the specific GPU model. Two machines running the same browser version can still produce pixel-level differences because one is rendering through an Nvidia driver and the other through Intel integrated graphics. The script hashes the resulting pixel buffer, and that hash becomes a stable identifier that persists across sessions, cookie clears, and IP changes.

This is why canvas fingerprinting is popular with detection vendors: it’s cheap to compute, it requires no user interaction, and it exposes real hardware and driver differences that are hard to fake convincingly because faking them means either running on genuinely different hardware or intercepting and rewriting the canvas API output in a way that itself can look inconsistent with everything else the browser reports.

Audio context fingerprinting

The Web Audio API works on a similar principle. A script creates an OfflineAudioContext, generates a signal (often a sine wave or triangle wave through an oscillator node), routes it through a dynamics compressor, and reads back the resulting audio buffer.

Audio processing on a real device runs through the actual audio stack: the sample rate the hardware supports, the specific implementation of oscillator and compressor nodes in that browser build, and floating-point rounding behavior that differs slightly between CPU architectures and operating systems. Even though nothing is played out loud, the numeric buffer that comes back carries small, consistent variations tied to the underlying hardware and software stack.

Like canvas, this produces a hash that’s stable for a given device and browser combination, and it costs the site almost nothing to run since it happens in milliseconds without any visible UI change.

Font enumeration and rendering signals

Font fingerprinting works differently depending on the method. The older approach is enumeration: a script tries to render text in a long list of font names and measures the resulting text width and height. If a font isn’t installed, the browser silently falls back to a default, and the measured dimensions match that fallback. If it is installed, the dimensions differ. Repeating this across a few hundred font names produces a list of which fonts are present on the machine, which is itself a fairly identifying signal because font libraries vary by OS, OS version, installed creative software (design tools bundle their own fonts), and region-specific language packs.

A newer and quieter approach reads font metrics directly through canvas text measurement (measureText()) without needing a visible list of font names at all, since the rendering differences alone leak information about the underlying font-rendering engine and installed font set.

Fonts matter to fingerprinting because they correlate with real-world identity signals that are hard to fake as a set. A machine reporting Adobe Creative Cloud fonts, a specific set of CJK language packs, and a Windows font-hinting profile paints a coherent picture of a real desktop. A synthetic environment that reports a font list mismatched with its claimed OS, or an oddly short and generic font list, stands out precisely because real machines rarely look that clean.

How these signals combine into a fingerprint

None of these three signals is decisive on its own. What makes device fingerprinting effective is combining dozens of signals like this, canvas hash, audio hash, font list, WebGL renderer string, screen resolution, timezone, installed plugins, hardware concurrency, into a composite fingerprint. Detection systems then look for two things: internal consistency and population rarity.

Consistency means checking whether the signals agree with each other. A user agent claiming macOS should come with a font list that matches macOS’s default fonts, a WebGL renderer string from Apple’s graphics stack, and canvas rendering behavior consistent with macOS’s font hinting. When automation frameworks spoof a user agent without correspondingly adjusting canvas and audio output, that mismatch is often more useful to a detection system than any single signal in isolation.

Rarity means checking how many other visitors share the exact same fingerprint. A completely unique combination of signals is memorable and easy to re-identify across visits, which cuts against anyone trying to look anonymous. But a fingerprint that’s suspiciously identical across thousands of sessions, which happens when a fleet of automated browsers all run the same environment configuration, is just as much of a signal in the other direction.

Why this matters for anyone running scraping infrastructure

Running proxy infrastructure at any real scale means confronting the fact that IP rotation and fingerprint management are separate problems. A clean residential IP behind a browser that reports a canvas hash shared by ten thousand other sessions, or an audio fingerprint that doesn’t match its claimed OS, gets flagged regardless of how clean the network path looks. This is one of the reasons headless browser detection has moved well past checking navigator.webdriver and now leans heavily on these rendering-level signals, because they’re expensive to fake convincingly and cheap for the site to check.

It’s also why browser automation tools differ so much in how they’re received by anti-bot systems. A framework that runs a real, unmodified browser engine on real hardware produces canvas and audio output that’s genuinely tied to that hardware, for better or worse. A framework that patches the canvas or audio API to return spoofed or randomized values can end up creating a different kind of tell: values that are internally inconsistent, or that change on every session in a way real hardware never would, since real GPU and audio stack behavior is stable for a given machine, not random per page load.

None of this makes any single tool undetectable or a detection system infallible. Fingerprinting is probabilistic. Sites tune their thresholds based on false positive tolerance, and a fingerprint that would get flagged on a payments page might pass unnoticed on a low-value content page. What’s consistent across the systems we’ve looked at is that they’re evaluating the whole signal set together, not any one piece of it.

How defenders actually use this

On the defensive side, canvas, audio, and font signals get folded into a device reputation score alongside behavioral signals like mouse movement, typing cadence, and navigation timing. A mismatched or overly generic fingerprint doesn’t usually trigger an outright block by itself. More often it raises a risk score that combines with other factors, IP reputation, request rate, session history, before a decision gets made to serve a CAPTCHA, throttle the request, or silently degrade the response. Understanding this layered approach is more useful for anyone building or evaluating scraping infrastructure than trying to defeat any single check, because the check that matters is rarely the one you can see.

If you’re building or auditing scraping and proxy infrastructure and want more breakdowns like this on how detection systems actually work, Data Research Tools covers the engineering side of fingerprinting, bot detection, and the pipeline tooling that has to account for it.

Get new guides and videos first — join the Telegram channel.