Audio, Font, and Hardware Fingerprinting: The Three Signals Most Antidetect Browsers Miss

Two months ago we ran an experiment. We took a competitor's $99/month antidetect browser — won't name names, but you've probably seen their ads — and tested 25 profiles against FingerprintJS Pro. Canvas fingerprints? All unique. WebGL? Properly spoofed. Every profile showed different GPU strings, different screen resolutions, different timezones.

Then we checked AudioContext.

Every. Single. Profile. Identical hash. Same font lists. Same hardwareConcurrency value. Twenty-five "different people" with the exact same audio hardware, the exact same fonts, and the exact same CPU. We actually triple-checked because we assumed we'd screwed up the test somehow. Nope.

If you think platforms aren't checking these signals, I've got bad news.

The Detection Vectors Nobody Talks About

Canvas fingerprinting gets 80% of the attention in antidetect marketing. WebGL gets the other 20%. Meanwhile, the signals that actually link accounts — AudioContext, font enumeration, and hardware APIs — get treated as afterthoughts. If they get treated at all. (If you're running privacy-first analytics with JustAnalytics, you've already seen how much fingerprint data typical scripts collect.)

Here's why that's backwards.

Canvas and WebGL are well-understood. Detection services like CreepJS and BrowserScan test for them explicitly. Every antidetect browser on the market knows they need to handle these vectors. So most of them do — at least well enough to pass the obvious tests.

But audio fingerprinting? Font enumeration? The Battery API? These vectors fly under the radar. They're harder to spoof at the JavaScript level. They require modifications to the browser engine itself, not just a wrapper that intercepts API calls. And because they're not in the standard "fingerprint test checklist," most antidetect vendors ignore them entirely.

The platforms haven't ignored them. Google's Trust Signals team has published research on audio fingerprinting since 2019. Amazon's account linking system (we've reverse-engineered portions of it based on ban patterns) heavily weights hardware consistency signals. Facebook's integrity system has been correlating AudioContext hashes with device IDs for years.

The detection side has moved on. The antidetect market? Still selling you canvas-only solutions at competitor prices and hoping you don't notice. Honestly, it's maddening. For teams doing ad verification across multiple geos or monitoring click quality via ClickzProtect, these fingerprint gaps translate directly to detection risk.

AudioContext: The Fingerprint You Can't Hear

Here's what happens when you visit a site that implements audio fingerprinting:

const audioContext = new (window.AudioContext || window.webkitAudioContext)();
const oscillator = audioContext.createOscillator();
const analyser = audioContext.createAnalyser();
const gainNode = audioContext.createGain();
const scriptProcessor = audioContext.createScriptProcessor(4096, 1, 1);

oscillator.type = 'triangle';
oscillator.frequency.setValueAtTime(10000, audioContext.currentTime);
gainNode.gain.setValueAtTime(0, audioContext.currentTime);

oscillator.connect(analyser);
analyser.connect(scriptProcessor);
scriptProcessor.connect(gainNode);
gainNode.connect(audioContext.destination);

oscillator.start(0);

scriptProcessor.onaudioprocess = function(event) {
  const output = event.inputBuffer.getChannelData(0);
  // Hash the output buffer — this varies by device
  const hash = hashFunction(output.slice(4500, 5000));
  console.log('Audio fingerprint:', hash);
  oscillator.stop();
};

No sound plays. The oscillator runs through a gain node set to zero. But the processing happens — and the output waveform differs based on your audio stack. The combination of your audio hardware, drivers, sample rate implementation, and the browser's audio processing code produces a unique (or near-unique) output.

Research from Princeton's WebTAP project measured audio fingerprinting at 3-5 bits of entropy. That's not huge by itself. But here's the thing: it's consistent. Your audio fingerprint doesn't change when you clear cookies. It doesn't change when you switch IP addresses. It persists across sessions — which makes it perfect for linking accounts that look "different" in every other way.

Most antidetect browsers handle this by doing... nothing. Literally nothing. The AudioContext API works normally, returns your real audio fingerprint, and nobody's the wiser. Until their accounts get linked and they're on Reddit asking "why did I get banned, I spoofed everything."

The ones that try to handle it usually just add noise to the output — randomizing the waveform slightly. This breaks consistency (same profile returns different hashes on each test) which is itself a detection signal. Real devices don't have inconsistent audio fingerprints.

What you actually need is a replacement audio fingerprint that's (a) different from your real one, (b) consistent across sessions, and (c) matches realistic audio hardware. That requires modifying the audio processing pipeline at the browser engine level. Chromium's audio code is in C++. You can't patch it from JavaScript.

JustBrowser handles this in the native engine — each profile gets an assigned audio fingerprint that produces consistent, realistic output from the oscillator/compressor chain. It's one of the reasons we forked Chromium instead of wrapping it.

Font Fingerprinting: Death by measureText()

Open your browser console and paste this:

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');

const fonts = ['Arial', 'Times New Roman', 'Comic Sans MS', 'Adobe Garamond Pro', 'Calibri', 'Menlo'];
const baseline = ctx.measureText('mmmmmmmmmmlli').width;

fonts.forEach(font => {
  ctx.font = `72px '${font}', monospace`;
  const width = ctx.measureText('mmmmmmmmmmlli').width;
  console.log(font, width !== baseline ? 'INSTALLED' : 'NOT INSTALLED');
});

This is font enumeration. Sites don't get direct access to your font list (that API was deprecated years ago for privacy reasons). But they can measure text width. Different fonts produce different pixel widths for the same string. By testing hundreds of font names against a monospace baseline, sites can determine exactly which fonts are on your system.

Your font list reveals:

Operating system — macOS ships with SF Pro and Menlo; Windows ships with Calibri and Segoe UI
Locale — CJK fonts indicate Asian language users; Arabic fonts indicate Middle Eastern users
Software installed — Adobe Creative Suite installs specific fonts; Microsoft Office installs others
Custom fonts — developers often install Fira Code or JetBrains Mono; these are signals

A 2024 study from KU Leuven measured font enumeration at 8-12 bits of entropy on typical populations. Higher than AudioContext. And like audio fingerprinting, it's persistent across sessions.

The problem for antidetect browsers: you can't just report a fake font list. If you claim Calibri is installed but measureText returns monospace dimensions, that's a detectable lie. If you inject fake font files, you've changed the system for all applications, not just the browser. If you randomize widths, consistency breaks.

The actual solution is to control which fonts the browser sees — presenting a curated font list that matches the profile's claimed OS and locale, with measureText results that correspond to real font metrics. This requires intercepting font enumeration at the browser level, not just lying to JavaScript about what's installed.

Most antidetect browsers don't do this. The ones that try often break rendering — text shows up wrong, spacing gets weird, sites look broken. It's a genuinely hard problem and I'll admit we underestimated it initially.

We spent four months getting font isolation right in JustBrowser. Four months. On fonts. Each profile has its own font stack that matches the spoofed OS. Windows profiles see Windows fonts. Mac profiles see Mac fonts. A profile claiming to be Ubuntu 22.04 sees the fonts that ship with Ubuntu. measureText stays consistent because the font substitution happens inside the engine's font cache, so metrics come from the font the profile actually renders with.

Hardware APIs: The Signals Hiding in Plain Sight

These are almost embarrassing. Like, I can't believe we're still talking about this in 2026:

console.log('CPU cores:', navigator.hardwareConcurrency);  // e.g., 8
console.log('Device memory:', navigator.deviceMemory);     // e.g., 8 (GB)

That's it. Two lines. Your CPU core count and RAM exposed to every website, no permissions required. No popup. No consent banner. Just... there for the taking.

navigator.hardwareConcurrency was added for Web Workers optimization — so sites could spawn an appropriate number of threads. But it turns out knowing someone has 8 cores vs 4 cores vs 16 cores is a useful fingerprint signal. Combine it with deviceMemory (rounded to 0.25, 0.5, 1, 2, 4, or 8 GB to limit precision) and you've got a hardware profile.

The Battery Status API is worse. On browsers that still support it (mainly Chromium-based, though it's being deprecated), sites can read:

navigator.getBattery().then(battery => {
  console.log('Level:', battery.level);           // 0.87
  console.log('Charging:', battery.charging);     // true
  console.log('Charging time:', battery.chargingTime);  // 3240 seconds
  console.log('Discharging time:', battery.dischargingTime);  // Infinity
});

Your exact battery level. Research showed this could identify users with high precision — your battery draining from 87% to 85% over a browsing session is a tracking signal. (Firefox removed Battery API support entirely in 2016. Chrome still has it.)

Combined, hardwareConcurrency + deviceMemory + battery signals contribute 5-8 bits of entropy. And almost no antidetect browser touches them.

We ran a test across five popular antidetect tools in March 2026:

Multilogin: hardwareConcurrency configurable, deviceMemory not spoofed
AdsPower: hardwareConcurrency randomized (breaks worker consistency), deviceMemory not spoofed
GoLogin: Neither spoofed
Dolphin Anty: hardwareConcurrency configurable, deviceMemory returns undefined (detectable as spoofing)
JustBrowser: Both spoofed per-profile with consistent values matching claimed hardware

Four out of five either ignore these signals or spoof them badly. This is the state of the market in 2026. We're not competing against geniuses here — we're competing against vendors who apparently never ran their own product through CreepJS. (If you're tracking outreach campaigns with JustEmails, fingerprint consistency matters for deliverability signals too.)

The Contrarian Take: These Vectors Matter More Than Canvas

Here's where I lose people. (I'm probably wrong about this. Maybe. But hear me out.)

I think audio, font, and hardware fingerprinting are more important than canvas fingerprinting for account linking. Not because they're higher entropy — they're not. But because everyone handles canvas, and almost nobody handles these.

If you're running 20 profiles and they all have unique canvas hashes but identical AudioContext fingerprints, you've already failed. The platform knows something is wrong. Maybe not which accounts are linked, but they know the pattern is synthetic. That triggers extra scrutiny on everything else.

The detection game isn't just about any single vector. It's about consistency across vectors. If your canvas says you're on a MacBook Pro M3, but your font list includes Windows-only fonts and your hardwareConcurrency is 4 (M3 chips have 8+ cores), something doesn't add up. Even if each individual spoof is "good," the combination is impossible.

This is where cheap antidetect browsers fail. They handle the easy stuff (canvas, WebGL, useragent) and ignore the hard stuff (audio, fonts, hardware). The result is profiles that pass basic tests but fail under real platform detection systems.

I'm not saying canvas doesn't matter. Obviously it does. But if you're choosing an antidetect browser and they can't explain how they handle AudioContext fingerprinting — walk away.

What This Means For Your Setup

If you're running multi-account operations, audit your current tool against these vectors specifically:

Test AudioContext consistency. Visit CreepJS on the same profile twice. Does the audio hash match both times? Now visit with a different profile — is the hash different? If the hashes match across profiles, you have a problem.
Check font enumeration. Use browserleaks.com or a similar tool. Does your profile's font list match the claimed OS? If you're spoofing macOS but showing Calibri and Segoe UI, platforms can see that.
Verify hardware spoofing. Open devtools, check navigator.hardwareConcurrency and navigator.deviceMemory. Are they different per profile? Do they match realistic hardware? (4GB RAM with 16 CPU cores is suspicious.)
Look at the full picture. Run a tool like CreepJS that aggregates multiple vectors. Check the "lies detected" section. Any inconsistency between vectors is a red flag.

For teams running ad verification workflows, these signals matter even more — your profiles need to look like real users in specific geos, not synthetic test rigs. We covered the broader workflow in our ad verification antidetect setup guide. If you're pairing antidetect profiles with click fraud protection from tools like ClickzProtect, make sure the fingerprints you're presenting are consistent with the locales you're monitoring.

A Prediction

By Q4 2026, audio fingerprinting will be in every platform's detection stack if it isn't already. The papers are published. The techniques are known. Google's already using it. The only question is how aggressively others adopt it.

When that happens, the antidetect browsers that didn't invest in native engine modifications will get crushed. You can't patch AudioContext from JavaScript. You can't fix font isolation with a browser extension. These are architectural decisions.

The market's going to consolidate around tools that actually modify the browser engine versus tools that just wrap it. We built JustBrowser as a native Chromium fork specifically because we saw this coming. Could be completely wrong — I've been wrong before, spectacularly — but check back in six months. If half the accounts on wrapper-based antidetects start getting linked, you'll know.

More on fingerprint vectors and detection testing on the JustBrowser blog. For a hands-on test, the JustBrowser trial runs seven days with nothing held back — spin up a handful of profiles, run them through CreepJS, and compare audio, font, and hardware signals against your current setup. If you're already using JustAnalytics for privacy-first tracking, the same profile isolation principles apply.

Or don't. Keep using whatever you're using, and keep hoping platforms don't check AudioContext. Your money, your accounts, your call.

Frequently Asked Questions

How does AudioContext fingerprinting work?

AudioContext fingerprinting works by processing a silent audio signal through the Web Audio API and measuring the output waveform. Different combinations of audio hardware, drivers, and browser implementations produce subtly different oscillator and compressor outputs. The resulting waveform hash is consistent across sessions but varies between devices — making it a reliable fingerprint signal that contributes 3-5 bits of entropy.

Can websites detect my installed fonts without permission?

Yes — websites enumerate fonts by measuring text width differences using canvas measureText(). A string rendered in Arial will have different pixel dimensions than the same string rendered in Times New Roman. By testing hundreds of font names and comparing widths against a baseline, sites can determine which fonts are installed on your system. This reveals your operating system, locale, and software (Adobe users have specific fonts, for example).

What hardware APIs leak fingerprint data?

navigator.hardwareConcurrency reveals your CPU core count. navigator.deviceMemory exposes your RAM (rounded to 0.25, 0.5, 1, 2, 4, or 8 GB). The Battery Status API (where still supported) leaks charging state and battery level. Combined, these signals create a hardware profile that contributes 5-8 bits of entropy and is rarely spoofed correctly by antidetect browsers.

Why don't most antidetect browsers handle these signals?

Most antidetect browsers focus on canvas and WebGL because those vectors are well-documented and easy to test. Audio, font, and hardware fingerprinting require deeper browser engine modifications — you can't just override a JavaScript property without breaking functionality or creating detectable inconsistencies. Native Chromium forks like JustBrowser can modify the audio processing pipeline and hardware API responses at the C++ level, while wrapper-based tools can't.

Try JustBrowser

Native Chromium antidetect browser — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so 40+ identity parameters are genuine, not faked. REST API for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower