Codec Support
See what this browser reports about recording containers and playback codecs — with "maybe" kept as "maybe".
MediaRecorder.isTypeSupported + canPlayType
Codec & Container Capability Report
What the browser reports about 14 recording and playback formats
Recording rows come from MediaRecorder.isTypeSupported(); playback rows come from canPlayType() on a matching media element. Both are capability answers from the browser's own tables: nothing is recorded, decoded, accelerated or negotiated here, and no row predicts call quality.
A missing optional format is not a fault — browser builds ship different codec sets. The Voice Recorder on this site is unaffected: it captures PCM and encodes a genuine WAV itself, so its downloads are .wav on every engine.
How to Test
- •Run the capability probe and read the Raw answer column — each row shows the literal value the browser returned.
- •Treat a Maybe row as uncertain, not as supported: canPlayType returns confidence strings, not booleans.
- •Check the How this was read column to see which API answered each row.
Browser Limitations
- •Both probes report the browser's own capability tables. Nothing here records, decodes, negotiates or hardware-accelerates media, and no row predicts call quality.
- •A missing optional format is normal — browser builds ship different codec sets. This page's Voice Recorder is unaffected because it encodes WAV itself.
Troubleshooting Tips
- •If a format is reported missing and a specific app needs it, try a different browser build — some Chromium builds on Linux ship without proprietary codecs.
About the Codec Support
The Codec Support asks two metadata APIs what this browser reports about media formats. Recording rows call MediaRecorder.isTypeSupported() for containers such as WebM with VP8/VP9/AV1, MP4 with H.264/AAC and audio-only WebM/Ogg. Playback rows call canPlayType() on the media element that matches the row’s kind — an audio mime string is never handed to a <video> element — for H.264, HEVC, VP9, AV1, AAC, MP3, FLAC and Opus.
Both are capability answers drawn from the browser’s own tables. Nothing is recorded, downloaded, decoded or accelerated while this page runs, so no row is evidence that a format actually works, that a codec is hardware-accelerated, or that a WebRTC call will negotiate it. Where the API cannot answer at all, the row says ‘API unavailable’ rather than reporting a negative, and a probe that throws is marked as an error instead of being folded into ‘missing’.
Tips for reading the report
- Read the Raw answer column: it shows the literal value the browser returned, so ‘probably’, ‘maybe’ and an empty string are all visible as themselves.
- Treat Maybe as uncertain. canPlayType returns confidence strings by design, so ‘maybe’ is not a soft ‘yes’ — it is the browser declining to commit.
- A missing optional format is normal rather than a fault; browser builds ship different codec sets, and some Linux Chromium builds ship without proprietary codecs.
- This page’s own Voice Recorder is unaffected by anything in the table: it captures raw PCM and encodes a genuine WAV itself, so its downloads are always .wav.
Common problems and fixes
A recording format shows as reported missing
Nothing is broken: an app built on MediaRecorder simply produces its recordings in a different container. That concern applies to other apps, not to this site’s Voice Recorder.
H.264 is reported missing
Chromium builds without proprietary codecs cannot decode H.264. Install a codec-complete browser build, or accept that a call or stream will negotiate VP8/VP9 instead — this page reports the fallback availability, it does not choose one.
Every row says API unavailable
Then the browser exposes neither MediaRecorder nor a usable canPlayType path, so no codec information could be gathered at all. That is an unsupported result, not a list of missing codecs.
Results differ between two machines with the same browser
Build configuration and platform codec licences differ. Trust each machine’s own report — this page is per-browser and per-build, not per-brand.
FAQ
Does this page download or play any media?
No. It queries MediaRecorder.isTypeSupported and canPlayType — both metadata-only calls. No media is fetched, decoded, or recorded, and nothing leaves your browser.
Why canPlayType returns “probably” or “maybe” instead of yes or no?
The HTML standard deliberately returns confidence strings, because real codec support depends on build flags and platform licences. ‘Probably’ is the strongest affirmative the API offers, and ‘maybe’ genuinely means uncertain.
Does this tell me whether my calls will be good quality?
No. These rows say what the browser claims about container and codec formats. Call quality also depends on the codec a session actually negotiates, the network, the capture hardware and the other end’s support — none of which this probe observes.
Can I add codecs to my browser?
Not usually. Support is compiled into each build. On Linux distributions that strip proprietary codecs, installing the standard branded browser build restores H.264/AAC.
A codec is reported missing — is my browser broken?
No. Codec sets differ between builds and platforms by design, and an optional codec is not required for normal web use. The Voice Recorder on this site encodes WAV locally, so it is unaffected either way.