A numerical signal, without recording sound
Audio fingerprinting in a browser does not have to involve a microphone. A webpage can create an offline audio graph, process a synthetic signal and inspect the resulting samples. Small implementation differences in audio processing can become another characteristic that a tracker combines with browser and device information.
This diagnostic uses an offline oscillator and dynamics compressor. It renders one second of synthetic audio, calculates a digest of the sample data and repeats the process. Nothing is connected to your speakers, and no microphone permission is requested. The result is a comparison of two computations, not a recording of your voice or an attempt to identify a room from background noise.
Follow the signal through the offline graph
The graph contains a triangle-wave oscillator at 10,000 Hz and a dynamics compressor with fixed threshold, knee, ratio, attack and release parameters. An OfflineAudioContext produces a mono buffer at 44,100 samples per second. The setup gives both runs the same instructions so that their numerical output can be compared under the current browser conditions.
The report includes a SHA-256 digest over the rendered floating-point sample buffer and the sum of absolute sample values from a fixed window. The digest is useful for exact equality comparisons. The sum is a human-readable numerical observation, but it is not a measure of privacy risk, audio quality or device value. Different graph recipes can produce completely different sums.
The byte representation being hashed belongs to this implementation. Comparing its digest with a hash from a different audio test is not meaningful unless both tools use identical graph parameters, sample selection and serialisation. The same general idea of an oscillator and compressor is not enough to establish an identical recipe.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Compare repeated processing rather than guessing causes
Matching hashes mean that the two offline renders produced the same sample bytes for this test. A mismatch says that the observations differed; it does not explain why. Browser privacy features can introduce variation, while audio implementation changes or execution conditions may also matter. Read the full report and repeat the check before attributing a difference to a specific extension.
To evaluate a browser setting, first record a stable baseline. Change one setting, restart the browser if required, and run the same page again. Record the version and profile. If you compare a laptop browser with a phone browser, you are changing the browser engine, operating system and hardware context together. That can answer whether the outputs differ, but not which component caused the difference.
Some privacy-oriented browsers standardise audio output or restrict offline rendering. A stable result can therefore be part of a privacy design. Random variation is not the only strategy. The relevant question is how the whole browser reduces cross-site recognition while preserving the functions you need, not whether this one test produces a visually dramatic number.
Handle unsupported and delayed rendering honestly
Offline audio support is widespread, but availability and execution behaviour can depend on browser policy. A constrained environment, background-tab policy or anti-fingerprinting protection may prevent a render from finishing promptly. The tool applies a timeout and reports an error rather than substituting a sample number. Running a check again in an active tab can help determine whether the condition repeats.
A timeout is not proof that all audio-based tracking is blocked. Other graphs, APIs or timing conditions may behave differently. The reverse is also true: a completed render does not mean a site has successfully identified you. It establishes only that this page obtained the described output under the current conditions.
Do not confuse this test with an acoustic fingerprint used to recognise a song, or a speaker-recognition model used to compare voices. Those systems analyse real audio content. This tool has no audio upload field, does not access media devices and does not compare the output with a population database. Its purpose is to make one browser behaviour visible and repeatable.
For reliable comparisons, keep the test tab active and avoid changing browser profiles mid-experiment. Record an unavailable result as an unavailable result in your notes. Substituting a previous successful number would erase the distinction between a new measurement and an earlier observation.
Readouts in the audio report
| Readout | Meaning |
|---|---|
| Sample rate: 44,100 Hz | The requested offline rendering rate, not a hardware microphone measurement. |
| Sample count: 44,100 | One second of synthetic mono output. |
| Absolute-value sum | Magnitude summary for a fixed sample window; not a risk score. |
| Matching digests | Identical sample bytes across the two observed runs. |
Strengths and limitations
What this is useful for
The test isolates a defined audio-processing recipe and provides exact outputs without permission prompts, playback or recording. Repeated runs help you investigate browser behaviour. The method is short enough to describe in full, which makes its results easier to reproduce than a hidden composite score.
What to keep in mind
The result does not establish uniqueness, identify a sound card or prove that audio-based tracking is impossible. Other graph recipes and browser versions can behave differently. A numerical match has meaning only in the context of this particular algorithm and its specified parameters.
Common questions
Can this hear me or use my microphone?
No. The test uses OfflineAudioContext and a synthetic oscillator. It does not request a MediaStream, call getUserMedia or read audio from any connected device. The generated signal is processed into a buffer rather than played through the speaker output.
Why did the value change after an update?
Browser updates can alter the implementation of audio processing, floating-point handling or privacy protections. The digest is designed to change when the sample bytes change. Compare the method, browser version and repeated results before deciding that the update created or fixed a privacy issue.
Are the samples sent to a server?
The audio graph, sample buffer and digest are produced in the browser tab. This application does not upload the output or compare it with other visitors. An exported report contains numerical summaries and hashes, not microphone audio or an audible recording.
Does the sum reveal my identity?
No identity conclusion follows from the sum alone. It is one numerical feature of one computation. Fingerprinting systems may combine similar observations with other signals, but this diagnostic has no population database and cannot tell how many people would produce the same result.