Media codec and DRM checks that identify you
Most people running multi-accounting setups spend their time worrying about canvas hashes and WebGL renderer strings. Fewer think about the media stack. That’s a mistake, because codec support and DRM checks are some of the hardest signals to fake convincingly, and platforms that care about fraud and account farming increasingly look at them.
This isn’t theoretical. I run real proxy and cloud-phone infrastructure and test anti-detect browsers against it daily. The codec and DRM layer is one of the places where a spoofed profile and a real device diverge in ways that are easy to check server-side and hard to patch client-side.
What a site can actually ask your browser
Two browser APIs matter here.
The first is HTMLMediaElement.canPlayType() and its more detailed successor, navigator.mediaCapabilities.decodingInfo(). A site calls this to ask the browser: can you decode this video codec, at this resolution, at this framerate, and will it be smooth and power efficient? The browser answers with real data pulled from the OS media framework: on Windows that’s Media Foundation, on macOS it’s VideoToolbox, on Android it’s the device’s hardware codec list via MediaCodecInfo. The browser isn’t guessing. It queries the actual decode pipeline available on the machine and reports back.
The second is the Encrypted Media Extensions (EME) API, navigator.requestMediaKeySystemAccess(). This is how a page checks for DRM support, most commonly Widevine on Chromium and Firefox, or FairPlay on Safari. The call asks for a specific key system and a robustness level, and the browser reports back what it can actually provision: whether hardware-backed decryption (Widevine L1) is available, or only the software fallback (L3). That distinction alone tells a site a lot about what kind of device it’s talking to, because L1 requires a real trusted execution environment tied to the hardware.
Neither of these checks is exotic. Streaming sites use them constantly to pick a codec and decide whether to serve HD content. Ad networks and anti-fraud vendors reuse the same calls because they’re cheap, standard, and revealing.
Why the codec list gives away more than people expect
Codec support isn’t just “Chrome supports these codecs.” It’s tied to the actual hardware and OS underneath. AV1 hardware decode showed up on GPUs and phone SoCs at different times depending on the chip generation. HEVC support in a browser is often gated by OS-level licensing, not just browser version, so a fresh Windows install and an older one can answer differently even on identical Chrome builds. Android devices report codec profiles and levels that map to the actual SoC’s media block, not to whatever the app claims to be.
That means the codec list is a fingerprint with structure. It’s not just “present or absent,” it’s a specific combination of container, codec, profile, resolution ceiling, and hardware-acceleration flag that correlates with a real device class. A profile claiming to be a mid-range Android phone but answering with a codec matrix that only ever shows up on a specific desktop GPU driver is an inconsistency a detection system can flag without needing anything else.
The DRM robustness tell
The DRM side is even blunter. When a page requests Widevine with HW_SECURE_ALL robustness, the browser either has a real hardware trust anchor to back that claim or it doesn’t. You can’t script your way into a hardware-backed security level from a plain automated browser process, because the provisioning goes through the OS and, on Chromium, through Google’s own Widevine CDM binary tied to a machine identity. Software emulation of a browser environment on a server, with no real GPU/TEE path, will either fail the L1 request outright or report L3, and that mismatch against a claimed device profile is exactly the kind of signal fraud teams look for.
This is also why virtualized or headless setups tend to show a flat, generic DRM answer regardless of what user agent or screen size is spoofed on top. The DRM layer sits underneath the parts of the browser that are easy to override with a JS injection or a profile config. You can change what navigator.userAgent says. You can’t as easily change what the Widevine CDM reports about the security level it actually has access to, because that answer comes from a binary component doing real provisioning, not from a string the anti-detect tool controls.
Where anti-detect browsers run into trouble here
Most anti-detect browsers do a solid job on the layer that’s pure JavaScript object spoofing: navigator properties, screen dimensions, timezone, language headers, canvas noise. That’s the layer built on data the tool fully controls. The media stack is different because it involves real system components: the GPU driver, the OS codec framework, and in the DRM case, a licensed CDM binary with its own device provisioning.
Some tools run on real, unvirtualized machines or real cloud phones and inherit a genuinely consistent codec and DRM answer because the hardware underneath is real. Others run in more virtualized or containerized environments and either can’t get hardware-backed DRM at all, or return a codec matrix that doesn’t match the spoofed device profile layered on top. I’m not going to hand out a verdict on specific vendors here without a test run in front of me to back it up, but the mechanism is the one to check yourself: pull up navigator.mediaCapabilities.decodingInfo() and requestMediaKeySystemAccess() results in a profile, and compare them against what a genuine device of the type you’re claiming to be would actually report. Public codec compatibility tables for major GPUs, Android SoCs, and browser versions exist and make this comparison possible without guesswork.
What actually holds up in practice
The honest takeaway from running real farm infrastructure is unglamorous: codec and DRM fingerprints are consistent when the underlying stack is real, and they’re inconsistent when it isn’t. Real cloud phones with genuine hardware decode paths answer these checks the way a real phone does, because there’s no spoofing layer between the API call and the actual chip. Desktop anti-detect profiles running on real GPUs with real drivers behave the same way for the desktop codec matrix. What breaks is the combination of a spoofed device identity sitting on top of a media stack that doesn’t match it, or a headless/virtualized backend that simply can’t answer the hardware-DRM question the way it’s being told to claim.
None of this makes any tool undetectable or a given account unbannable. Codec and DRM checks are one signal among many that a detection system can weigh, and platforms combine them with behavioral data, IP reputation, and account history. A clean codec and DRM answer doesn’t offset a residential-looking proxy that’s actually a datacenter IP, or a browsing pattern that looks scripted. Treat it as one more place where consistency between your claimed identity and your actual stack matters, not as a switch you flip and forget.
If you’re evaluating anti-detect browsers for multi-accounting work, checking the codec and DRM layer against the device profile you’re claiming is a fast, concrete test you can run yourself before trusting a vendor’s marketing page.
For more breakdowns like this on how browser fingerprinting actually works and which anti-detect tools hold up under real testing, head back to the homepage.
Get new guides and videos first — join the Telegram channel.