Audio fingerprinting and how it cross-references with Canvas

Most people who run multi-account operations think about fingerprinting in terms of what they can see, canvas pixels, WebGL renderer strings, screen resolution. audio fingerprinting flies under the radar because there is no visible output. no image gets drawn. nothing gets rendered to the screen. yet it is one of the more stable signals a tracking script can collect, and when it is combined with canvas data, the two signals cross-reference each other in ways that make spoofing either one individually much less effective.

if you are new to browser fingerprinting and trying to understand why your antidetect browser is not doing enough, or why two supposedly separate accounts keep getting flagged as the same person, audio fingerprinting is probably part of the answer. this explainer walks through what it is, how it actually works at the browser level, and what it means for anyone running multi-account workflows.

what it is

audio fingerprinting is a technique that uses the Web Audio API, a browser feature originally built for games and interactive audio applications, to extract a unique value from the way your device processes sound.

it does not record your microphone. it does not play any audio you can hear. instead, it generates a silent audio signal internally, runs it through the browser’s audio processing stack, and reads back the numerical output. because different hardware (your CPU, your audio codec chip, your operating system’s audio libraries) processes floating-point arithmetic slightly differently, the output value is different from device to device. that value becomes part of your fingerprint.

on its own, the audio hash is one signal among dozens. but its value multiplies when it is correlated with canvas fingerprinting. canvas fingerprinting works by drawing shapes or text to an HTML5 canvas element and reading back the pixel data. the pixel rendering is also hardware-dependent, affected by your GPU, driver version, and OS font rendering. the combination of these two hardware-dependent signals, one from your audio stack and one from your graphics stack, gives trackers something much more distinctive than either signal alone.

how it works

the mechanics are worth understanding in some detail because they explain why naive spoofing fails.

a tracking script calls AudioContext() to create an audio processing context in the browser. it then creates an OscillatorNode, which generates a sine wave at a specific frequency, typically 10,000 Hz. it routes that oscillator through a DynamicsCompressorNode, a signal processing node that introduces small nonlinear transformations. the processed signal is passed to an AnalyserNode, and the script reads back the frequency domain data as a typed array of floating-point numbers.

the key is in the compressor step. the DynamicsCompressorNode applies loudness compression, and the coefficients it uses depend on the underlying audio implementation. on macOS, the implementation goes through Core Audio. on Windows, it goes through WASAPI or DirectSound depending on the browser version and audio driver. on Linux, it typically goes through PulseAudio or ALSA. each of these produces subtly different floating-point rounding in the output array. the script hashes that array and stores it.

fingerprintjs, the commercial fingerprinting vendor, documented this technique publicly in 2021. their implementation is widely referenced because they open-sourced the core library before commercialising the pro version.

for canvas, the parallel is the GPU path. a script draws text, curved shapes, and gradients to a canvas element, then calls canvas.toDataURL() to get the pixel data as a base64 string. the exact pixels depend on which GPU you have, which driver is installed, how anti-aliasing is implemented, and how font rendering works on your OS. that base64 string gets hashed too.

cross-referencing happens at the collector side. if your audio hash and canvas hash both match a previous session’s hashes, a fraud or risk system can conclude the same physical device is present regardless of what IP address, cookie, or user account is attached to the request. if only one of the two matches, the system may still assign a moderate risk score rather than a clean pass. this is why spoofing canvas alone while leaving audio untouched is enough to get flagged on sophisticated platforms.

why it matters

for multi-account operators. if you are running separate accounts on a platform like an affiliate network, an e-commerce marketplace, or a social platform, and those accounts are supposed to represent distinct entities, matching audio and canvas hashes are strong evidence that they originate from the same physical machine. platforms running fingerprint-based risk scoring, including many that use Sift, Sardine, or ThreatMetrix, will correlate these signals across account sessions.

for antidetect browser users. most antidetect browsers address canvas by injecting noise into the pixel output or by returning a preconfigured static canvas hash per profile. audio is handled less consistently. some tools, including older versions of Multilogin and some cheaper alternatives, did not spoof audio at all until relatively recently. if you are evaluating an antidetect browser, testing audio fingerprint consistency across profiles is a non-negotiable check. tools like BrowserLeaks let you verify this for free.

for fingerprint stability. audio fingerprints are more stable than many other signals because they depend on hardware and system-level audio libraries, not on browser state that changes between sessions. cookies expire. localStorage can be cleared. IP addresses rotate. an audio hash from a specific laptop running a specific OS version tends to stay consistent across browser updates, which is why fraud systems weight it highly.

for anyone interested in how tracking actually works. the W3C Web Audio API specification does not include any privacy protections against this use case. the spec was written for audio applications, not for identity resistance. browsers like Firefox have started adding audio fingerprinting mitigations in private browsing mode, but standard browsing contexts remain fully exposed on most browsers as of 2026.

common misconceptions

“disabling javascript stops audio fingerprinting.” technically true but practically useless. disabling javascript breaks almost every website you need to use. it also makes your browser fingerprint highly distinctive in its own right, a browser with javascript disabled stands out immediately in fingerprint datasets.

“using a VPN changes my audio fingerprint.” a VPN changes your IP address. it does not touch your browser’s audio processing stack. your audio hash is generated locally on your device and is completely independent of your network path. two sessions from the same machine will produce the same audio hash whether you are on a home connection, a datacenter proxy, or a residential IP.

“canvas noise injection is enough.” some operators add random noise to canvas output and assume that solves the problem. a consistent audio hash across profiles will still correlate those profiles, and if the canvas noise is poorly implemented, it may be detectable as artificial anyway. both signals need to be independently managed.

“only big platforms use this.” audio fingerprinting is available to any site that runs javascript. the fingerprintjs open-source library has millions of downloads. smaller affiliate networks and ad verification vendors use the same techniques as larger platforms. assuming you are only at risk from large tech companies is a mistake that gets people burned on mid-tier networks too.

where to go from here

if this is your introduction to fingerprinting, audio and canvas are two signals among a broader set. here are the topics worth understanding next.

• canvas fingerprinting explained, my breakdown of how GPU-based pixel rendering becomes an identity signal and what realistic mitigation looks like.
• WebGL fingerprinting and the renderer string, which covers the GPU-level signal that often correlates directly with canvas output.
• how antidetect browsers handle fingerprint injection, a more operational article on what the major tools actually do under the hood and where they fall short.
• for context on how these fingerprinting signals interact with proxy and multi-account infrastructure, the multiaccountops.com blog covers operational setups where fingerprint consistency across profiles is a live concern.

the fingerprint.com documentation is also worth reading if you want to understand what a commercial implementation looks like from the collector side. understanding what you are being measured by is the starting point for understanding how to manage it.

the short version: audio fingerprinting is a hardware-level signal that does not require any permissions, produces no visible output, and is more stable than most browser-state signals. when it correlates with canvas output, the two together form a reliable device identifier that persists across sessions, IP changes, and account switches. if you are running any kind of multi-profile operation and you have not verified that your tooling handles audio fingerprinting independently per profile, that gap is worth closing.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.