Codec & Media Support Test

This page asks your browser which video and audio formats it can actually play. It probes MP4 with H.264, HEVC and AV1, WebM with VP8 and VP9, the Ogg container, and the audio codecs AAC, Opus, Vorbis, FLAC, ALAC, MP3 and PCM. Each answer comes from the same capability check a real media player uses before it tries to load a file.

The result is a practical map. It tells you whether a downloaded video will open, whether a video call site can use the efficient codec it prefers, and whether an audio file in an unusual format will play at all. It also reveals the packaging choices behind your browser, since the same Chromium build can include or omit proprietary codecs depending on who compiled it.

The whole test rests on one method, canPlayType, called on a media element that is never added to the page. You hand it a MIME type such as video/webm; codecs="vp9" and it returns one of three strings. probably means the browser is confident. maybe means the answer depends on something it cannot determine from the string alone, often the exact profile or level inside a codec family. An empty string means the format is not supported.

The method is a lookup, not a decode. It consults the list of decoders the browser has registered and answers immediately, which is why every chip above appears the moment the page loads. That speed is also its weakness: it can promise support the machine cannot deliver at the resolution you actually want, because a decoder that handles a low-profile stream may struggle with a high-profile one on the same hardware.

The MIME string matters as much as the codec name. Adding a codecs parameter narrows the question, and leaving it off asks only whether the container is recognised at all.

A container is a wrapper, and a codec is the compression inside it. MP4 and WebM are containers; H.264, VP9 and AV1 are video codecs; AAC, Opus and Vorbis are audio codecs. Support is decided per combination, which is why the test probes both separately and together. A browser that plays H.264 inside MP4 may refuse the same video inside WebM.

Profiles add another layer. H.264 has Baseline, Main and High profiles, each with its own feature set, and the test asks about all three because older hardware sometimes decodes only the simplest. AV1 is the newest of the group and the most variable: where it is present it is usually decoded in hardware on recent chips and in software elsewhere, and the answer reflects that split.

On the audio side the container matters too. Opus is widely supported in WebM and Ogg but was historically absent from Safari, while AAC is close to universal. The audio fingerprint test uses the Web Audio API, which is a separate system again.

Two related APIs answer narrower questions. MediaSource lets a page feed video into a player in segments rather than as a single file, which is how adaptive streaming works, and MediaSource.isTypeSupported asks whether a specific type can be streamed that way. Its answer is stricter than canPlayType, because the browser has to be able to parse and append fragments, not just decode a finished file.

MediaRecorder.isTypeSupported covers the opposite direction: which formats the browser can encode from a camera or microphone stream. A browser may happily play VP9 while refusing to record it, so the two lists genuinely differ. Recording also costs CPU, and hardware encoders are far less widely available than decoders, which is why that list is usually the shorter one. The media devices test covers the inputs those recordings would come from.

Treat every answer above as a strong hint rather than a guarantee. The check happens before any media is fetched, so it cannot account for a file that uses an unusual profile, an odd resolution or a container feature the decoder rejects on contact. It also says nothing about performance: a software decoder can report full support and then drop frames on a modest CPU.

Support is also not fixed in time. Codec availability changes with browser releases, operating system updates and hardware, and a machine that answers maybe today may answer probably after a driver update adds hardware decoding. Nor does any of this cover DRM, which sits above the codec layer and requires a licence exchange to test properly. For a wider view of what your browser reports about itself, the browser information test and the hardware test fill in the rest.