What WebCodecs can and cannot do in the browser

What the API gives you

Before WebCodecs, a web page had two ways to deal with video. It could hand a file to a <video> element and let the browser play it, with no access to the frames. Or it could ship an entire codec compiled to WebAssembly and do everything in software, which works and is slow and costs several megabytes of download.

WebCodecs exposes the codecs the browser already has. Four interfaces matter here:

• VideoDecoder turns encoded chunks into frames.
• VideoFrame is a single frame you can draw, read and edit.
• VideoEncoder turns frames back into encoded chunks.
• EncodedVideoChunk is one compressed frame in or out.

Notice what is missing: containers. WebCodecs handles codecs, not file formats, so nothing in it knows what an MP4 is. Getting chunks out of a file and back into one is a separate job, handled here by a muxing and demuxing library. This split is deliberate and it is the right call, but it does mean "WebCodecs support" alone never tells you whether a given pipeline will run.

Decoding is the easy half

Every browser that plays video already contains decoders, because playing video is the whole point of a <video> element. Exposing them through an API is mostly a matter of wiring, and decode support has consequently arrived broadly.

Encoding is a different proposition. A browser does not need an H.264 encoder to play video, so whether one is present at all depends on what the vendor chose to ship. Shipping one brings in licensing considerations that have historically made vendors cautious about H.264 specifically, and the encoder that does ship may be software only, hardware accelerated, or hardware accelerated on some machines and not others.

This is why a browser can play a cleaned clip perfectly and still be unable to produce one. Playing needs a decoder. Producing needs an encoder. They are not the same component and they are not shipped together.

Why the tool asks for Chrome or Edge

In practice, H.264 encoding through VideoEncoder is what the video tool depends on, and Chrome and Edge are where it is reliably available. Both are Chromium based, so they share the implementation.

Safari and Firefox have both been adding WebCodecs, and the picture has moved more than once. Rather than publishing a matrix that will be wrong in six months, the tool asks the browser directly. So can you:

const support = await VideoEncoder.isConfigSupported({
  codec: 'avc1.42001f',
  width: 1280,
  height: 720,
  bitrate: 12_000_000,
  framerate: 30
});

console.log(support.supported);

If that logs true, the browser can encode H.264 at that configuration. If it logs false, or VideoEncoder is undefined entirely, the pipeline cannot run there whatever the release notes say.

Configuration the browser may quietly ignore

VideoEncoder.configure() takes a set of preferences, and some of them are hints rather than instructions. Three are worth knowing about, because all three can be accepted without taking effect.

hardwareAcceleration

You can ask for prefer-hardware, and the request can simply be rejected, leaving you on a software encoder. That is not a failure state, it is a normal outcome, and the pipeline has to work either way.

bitrate

The bitrate is a target the rate controller aims at. An encoder that is unwilling or unable to reach it will produce what it produces. Asking for 12 Mbps and receiving 4 is an ordinary result rather than a bug, and the gap between request and reality is large enough that it is worth measuring rather than assuming.

contentHint

This one deserves genuine caution. It tells the encoder what kind of material it is looking at, and setting it to detail sounds like asking for more detail. On Chrome's software H.264 encoder it selects a mode tuned for screen content, which on camera footage stalls rate control at roughly a quarter of the requested bitrate and costs about four decibels of picture quality.

That result is measured rather than inferred, and the measurement is written up in measuring what a browser re-encode costs you.

Codecs other than H.264

VP9 and AV1 are royalty free, which removes the licensing question that complicates H.264, and both are widely decodable. Encoder availability is patchier, and in testing neither produced better output than H.264 at the same settings for this material. HEVC encoding was not available at all.

There is also a compatibility argument for staying on H.264. An MP4 with H.264 video plays essentially everywhere, including on phones, in editors and on platforms that will re-encode it again anyway. A technically superior file that a recipient cannot open is not superior in any way that matters.

What this means if you are on Safari or Firefox

The image tool works everywhere. It needs canvas and arithmetic, nothing more, and there is no encode step because PNG is written directly.

The video tool needs an H.264 encoder in the browser you are using. If the page reports that your browser cannot encode video, that is a straightforward statement of what the feature test returned, not a preference. The clip you are trying to clean will play fine in that browser once another one has produced it.

This constraint is genuinely temporary. As encoder support broadens, the same code will start working in more places without changing, because the requirement is expressed as a capability check rather than a browser list.