Skip to content
All fingerprint checks
Navigator identity

The AAC encoder is present or absent as the claimed platform's Google Chrome ships it

Pim· Clearcote Research 3 min readCheck id webcodecs-aac-vs-chrome-branding

A build claiming the "Google Chrome" brand on Windows or macOS encodes mp4a.40.2 through WebCodecs AudioEncoder; on Linux it reports mp4a.40.2 unsupported, as Google Chrome for Linux does. The row declines for a build not claiming that brand, and when no desktop OS is claimed.

What a detector infers

This is the licensed-codec argument asked at the encoder rather than the decoder, and the platform decides the answer. Google Chrome has no AAC encoder of its own: Chromium's FFmpeg is built with every encoder switched off, and WebCodecs reaches AAC only through the operating system's encoder — Media Foundation on Windows, AudioToolbox on macOS.

Linux has no such encoder, so Google Chrome for Linux reports mp4a.40.2 unsupported to AudioEncoder (and to MediaRecorder) while decoding AAC everywhere; measured on genuine Chrome 154 for Linux, headless and headed, on a server and in Docker.

So the brand implies an encoder on Windows and macOS and implies its absence on Linux, and either contradiction is worth knowing: a Windows or macOS claim without the encoder is the shape a Linux host serving a desktop persona produces, and a Linux claim with one is a Windows or Mac host behind a Linux persona.

A yes is only accepted once a short buffer has actually encoded, because isConfigSupported reads whether the platform-encoder feature is on rather than resolving an encoder: genuine Chrome on Linux with that feature forced on answers supported and then fails every encode — an API promising a capability the binary does not have, the worst of these shapes.

Gated to the Google Chrome brand exactly as the other branding rows are, which exempts every bare-Chromium derivative by construction, and warn rather than critical because Windows N without the Media Feature Pack, or a policy that removes Media Foundation, produces the same reading as a missing encoder.

How to resolve it

Claim the platform the encoder belongs to: run a Windows or macOS persona on a host of that OS, and claim Linux on a Linux host, where reporting AAC encode as unsupported is the genuine answer. Do not force the platform-encoder feature on or patch isConfigSupported to say yes on Linux — the claim and the encoder then disagree on the first encode, which is a stronger tell than the absence. A build that does not claim the Google Chrome brand is exempt from this row entirely.

Anatomy of a browser fingerprint: every signal, and why they must agree

Read in the wild by

CloakBrowser issues

A stealth-browser tracker records the WebCodecs encoder surface disagreeing with the codec support the same build advertises through the media element.

CloakHQ/CloakBrowser #146, #142 (WebCodecs / AAC support vs claimed build)

CloakHQ/CloakBrowser#146

Every attribution traces to a published artifact. See the sources and their limits.

Nearby checks in Navigator identity

See all 43 checks in Navigator identity
Who builds this test

Clearcote is a browser built for fingerprint coherence

It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.

This audit takes no position on how Clearcote scores on Navigator identity checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.

See the other checks in Navigator identity — the family webcodecs-aac-vs-chrome-branding belongs to.