What Is WebAssembly Fingerprinting?

Most code on a web page is JavaScript: the browser reads it and runs it line by line. WebAssembly (WASM) is different. It is pre-compiled code that runs almost as fast as a native app, and it can use SIMD instructions — single commands that do the same piece of math on several numbers at once (the kind of work a CPU does for video or graphics). An anti-bot ships a tiny WASM module that runs these instructions in a fixed pattern and times them very precisely.

Why does timing reveal anything? Because different processors finish the exact same work in slightly different ways. Those measurements expose details like how wide the chip's math registers are and which instruction families it supports — NEON on Apple and other ARM chips, SSE on older Intel/AMD, AVX on modern x86 — plus tiny quirks unique to each CPU model. It is a bit like recognising a car from the precise sound of its engine instead of the badge on the front.

Here is the key point for scraping: stealth browsers change what the browser reports about itself, but WASM SIMD measures the real silicon. A genuine Mac with an M2 chip cannot be dressed up to look like an Intel laptop, because the timing fingerprint comes from the chip, not the browser. Source: Anthony Manikhouth, DataDome detection engineer, blog.azerpas.com, May 2026.

To fingerprint by timing, an anti-bot first needs an accurate stopwatch — and browsers deliberately make their normal one blurry. On ordinary pages Chrome rounds performance.now() to the nearest 100 microseconds, so that hostile sites cannot use ultra-precise timing to spy on the CPU (a family of attacks known as Spectre).

WASM quietly undoes that blur. A single line — new WebAssembly.Memory({shared:true}).buffer — creates a block of shared memory that a background thread (a Web Worker) can count upward as fast as it can using Atomics.add. Reading that counter acts as a stopwatch ticking about 100,000 times a second: fine enough to tell apart events roughly 6 microseconds apart, about 17× sharper than the timer Chrome means to hand out. (A microsecond is a millionth of a second.)

With a stopwatch that precise, an anti-bot can measure tiny timing differences in things like canvas drawing, JavaScript execution and animation frames — and those differ between real human machines and bots at the sub-millisecond level. This was reported to Chrome as bug 40057687 and marked Won't Fix. Source: Manuel, brokenbrowser.com.

The third WASM trick has nothing to do with the CPU. It checks which hyphenation dictionaries the browser ships — the rules that decide where a long word is allowed to break at the end of a line. The three main browser engines bundle slightly different ones: Blink (the engine inside Chrome), Gecko (inside Firefox) and WebKit (inside Safari). A WASM probe feeds in a known phrase, watches where the browser splits it, and from that works out the real engine underneath — even if the User-Agent string (the line of text a browser sends to identify itself) claims something else.

This catches a specific class of scraper: Camoufox claiming to be Chrome. Camoufox is Firefox under the hood, so its Intl hyphenation matches Gecko. A request with a Chrome User-Agent but Gecko hyphenation is unmistakably a Firefox-based stealth tool. Akamai's sensor.js and DataDome's WASM challenge both include this check.

The defence is the same as for the other WASM probes — patch the engine below the JS layer, or use a tool whose hyphenation matches its claimed UA. There is no JS-level workaround.

The decade-long focus on JavaScript-layer browser configuration has hit a ceiling, because this round of fingerprinting happens below the JavaScript layer. A few practical observations: WASM probing is expensive to deploy, so it is concentrated on the most heavily defended sites (the machine-learning systems run by the largest anti-bot vendors). On those targets, a browser running below-the-JS-layer configuration may still differ from real consumer hardware. Over time, the closest match to a real browser will come from real consumer hardware on real ISP networks rather than cloud-hosted browser instances.