Audio fingerprinting: why the readback stays honest

Audio fingerprinting sounds like something that needs a microphone. It needs nothing of the kind: the page never plays a sound and never asks for a permission. It asks the browser to compute one, reads the numbers back, and the tiny differences in how each machine computes them become an identifier. For anyone running many browsers, the tempting answer is to add a little noise to those numbers, and that answer is what this article is mostly about.

What is audio fingerprinting in a browser?

Audio fingerprinting in a browser is rendering a short signal through the Web Audio API into an offline buffer, reading the samples back and turning them into a number. It is a different thing from the acoustic fingerprint that identifies a song from a recording; nothing is heard or recorded. Fingerprint, the company that sells browser identification, publishes the recipe in an article on audio fingerprinting by its engineer Sergey Mostsevenko, dated 9 July 2025.

The same recipe returned 101.45647543197447 in Chrome on macOS, 79.58850509487092 in Safari and 80.95458510611206 in Firefox. Fingerprint found that every browser on its test laptops produced a different value, and that the value "is stable and remains the same in incognito mode". How the FingerprintJS signal anti_detect_browser came to fire on one bundled file is covered in FingerprintJS and anti_detect_browser.

Can a website fingerprint a browser through the audio API?

Yes. A website can read an audio value that depends on the browser engine, the operating system and the processor, without any permission or user gesture. Fingerprint attributes the variation to "underlying hardware and OS", to per-architecture code paths and to floating point arithmetic, and rates the signal as "highly stable" while it contributes "only slightly to uniqueness". Many machines share a value, and that makes it a check of consistency as much as an identifier.

The audio API exposes static properties as well, and Chrome rounds one of them on purpose. Chromium's audio context source states that without microphone permission "the outputLatency property is quantized by 8ms to reduce the precision for privacy concerns". Every Chrome therefore reports its output latency on an 8-millisecond grid. We read these values in four browsers on one Windows machine on 14 September 2026, 10 runs each.

A value off that grid exists in no Chrome, and a checker needs one division to find it. Our 151 build reported one: its persona computed the output latency instead of taking the device's, and the result sat between two grid points. The 154 engine, shipped on 20 September 2026, reports the audio device's own values, as the last row shows and a second reading of the shipped build confirmed on 16 September 2026.

Why is added noise on audio a tell?

Added noise on audio is a tell because every way of adding it leaves either a trace a checker sees or a structure an attacker can remove. On 5 July 2026 we ran three designs for the audio buffer against two public checkers, CreepJS and BrowserScan, and against a simple attack.

The first two designs fail in opposite directions, and that is the point. Noise that is uniform enough to stay invisible has a structure, and a structure can be measured and removed; noise that breaks the structure adds variance a checker can measure. The removal is not hypothetical: Fingerprint's article describes it for Brave, whose standard mode multiplies the audio by one factor, as getting "back the original buffer by dividing the farbled values by the fudge factor". Only the third design survived both the checkers and the attack, so audio returns what the device computes.

Canvas taught the same lesson in the same week. An offset of up to 2 per colour channel gave 5 of 5 profiles on one machine distinct canvas hashes, and BrowserScan flagged the canvas as manipulated. Outside our own tests, Hoang Dai Nguyen and Phani Vadrevu at Louisiana State University analysed the canvas defences of 18 extensions and 5 browsers in Breaking the Shield (WWW 2025), attacked every randomisation among them and showed that "their supposed nondeterministic behavior can, in fact, be predicted and exploited". Audio and canvas are two of the readback surfaces where the rule is the same.

What do the other readback surfaces report?

The other readback surfaces report the device's own values too: canvas, WebGL, WebGPU, measureText and audio all return what the machine produces, with no added noise. The cost is deliberate. Profiles on the same machine share one audio value and one canvas hash, exactly like every other machine with the same hardware and drivers, and the coherence page explains why a shared honest value is the better trade than a unique invented one.

Which browsers add noise to audio on purpose?

Three browsers treat the audio value differently on purpose, according to Fingerprint's article, and each one does it as part of its own identity.

• Safari 17 and later "injects random noise into audio signals generated via the Web Audio API when in Private Browsing mode".
• Brave multiplies audio values by a fixed number per site and session in its standard mode, and replaces the wave with "a pseudo-random sequence" in strict mode.
• Tor Browser has the Web Audio API disabled.

Noise is therefore an expected answer from Brave or from Safari in private mode, and an unexpected one from a browser that presents itself as Chrome. A checker that knows which brand adds noise reads the noise as a contradiction of the brand.