WebCodecs vs ffmpeg.wasm: why we switched our video compressor

When we started prototyping the Motionix video compressor, we planned to ship ffmpeg.wasm. It's the obvious choice — every web video tool has used it since 2019. Less than a month in, we tore it out and replaced it with Mediabunny + straight WebCodecs. Here's why.

The ffmpeg.wasm assumption

The pitch is simple: bundle ffmpeg as WASM, run it in a worker, get a full video toolchain in 4 KB of code calls. Reality in 2026:

• Download size. WASM bundle is ~8.5 MB gzipped. That's a one-time hit, but on a 3G connection it's 30+ seconds.
• Memory usage. ffmpeg.wasm loads the entire video into memory. A 200 MB video needs 400+ MB of RAM.
• Speed. WASM runs at ~60% of native speed. A 5-minute transcode takes 8+ minutes in the browser.
• Codec support. H.264 encoding works, but hardware acceleration is unavailable from WASM.

The WebCodecs alternative

WebCodecs is a browser API that exposes the same hardware video encoders that native apps use. It's available in Chrome, Edge, Safari 16.4+, and Firefox 130+.

• Download size. Zero. The API is built into the browser.
• Memory usage. Streams frames — doesn't load the entire video into RAM.
• Speed. Hardware-accelerated. A 60 MB MP4 transcodes in 30-60 seconds on a typical laptop.
• Codec support. H.264 with hardware encoding. AV1 support coming.

The numbers

Why we chose WebCodecs

1. No download cost. Users don't wait for an 8 MB WASM bundle.
2. Hardware acceleration. Modern laptops have dedicated video encoders. Using them is 3-4x faster.
3. Streaming processing. We process frames one at a time instead of loading the entire video.
4. Better user experience. A 60 MB video compresses in under a minute instead of 5+ minutes.

The trade-off

WebCodecs is now supported across the major desktop browsers, including Firefox 130+, so the reach gap has largely closed. It still needs a reasonably recent browser and isn't available in Firefox for Android, so we keep an ffmpeg.wasm fallback for those older and mobile cases — exactly the broad-reach advantage that keeps ffmpeg.wasm relevant.

How each works in-browser

The two approaches solve the same problem at completely different layers of the stack.

ffmpeg.wasm is the entire FFmpeg C codebase compiled to WebAssembly. You hand it the same command-line arguments you would type in a terminal (-i input.mp4 -c:v libx264 ...), and it runs a software encoder inside a sandboxed VM. Nothing touches the GPU; every transform and motion-estimation pass runs as portable WASM instructions on the CPU.

WebCodecs is a thin browser API (VideoEncoder, VideoDecoder, VideoFrame) that hands raw frames straight to the operating system's own media stack — the same hardware encoder block that Chrome, your camera app, and native video editors use. You still write the demux and mux glue yourself (we use Mediabunny), but the heavy lifting happens in silicon.

That single architectural difference — software VM versus hardware passthrough — produces every number in the table above.

Performance and file-size trade-offs

Speed is the headline, but the subtler win is consistency:

• Throughput. Hardware encoding via WebCodecs runs at roughly 2x realtime on a mid-range laptop; ffmpeg.wasm runs at about 0.5x. On a 5-minute clip that is about 2.5 minutes versus 10.
• Memory ceiling. WebCodecs streams frames, so peak RAM stays near 50 MB regardless of clip length. ffmpeg.wasm's in-memory model means a 200 MB input can spike past 400 MB and crash a mobile tab.
• File size at a target quality. Here ffmpeg.wasm actually edges ahead. Software libx264 at a slow preset can produce a file 5-15% smaller than a hardware encoder at matched visual quality, because hardware encoders trade some compression efficiency for speed. If your only goal is the smallest possible file and wait time is irrelevant, software encoding still wins.

So the trade is explicit: WebCodecs buys speed, memory safety, and a zero-byte download; ffmpeg.wasm buys a slightly smaller file and broader codec support, at a steep cost in time and memory.

Browser support in 2026

• Chrome and Edge: full VideoEncoder and VideoDecoder support since v94, with hardware H.264 and VP9, broad AV1 decode, and AV1 encode on newer GPUs.
• Safari 16.4+: WebCodecs shipped, including hardware H.264 — this is what let us drop the WASM fallback on Mac and iOS.
• Firefox: VideoEncoder shipped in Firefox 130 (September 2024), enabled by default with no flag — so as of 2026 WebCodecs encoding works in Firefox too.

As of 2026, WebCodecs encoding is available by default on every major desktop browser (Chrome/Edge 94+, Safari 16.4+, Firefox 130+). The genuine caveats are now mobile — Firefox for Android still lacks VideoEncoder — and users on older browser versions that predate these releases.

ffmpeg.wasm, by contrast, runs anywhere WebAssembly and SharedArrayBuffer do — which today is every current browser, as long as the page is cross-origin isolated with the right COOP and COEP headers. That universality is its remaining advantage.

Which to choose

To see the practical workflow rather than an API comparison, use the GIF maker guide. It explains the current frame-rate recipes, output limits, and why a browser-supported MP4 source is a safer first test than relying on the container extension alone.

• Choose WebCodecs when speed and a zero-byte download matter, your target codecs are H.264 or VP9, and you can ship a fallback for older or mobile browsers (Firefox for Android, dated versions). This is the right default for a consumer tool.
• Choose ffmpeg.wasm when you need format and codec breadth (obscure inputs, audio filtergraphs, subtitle burn-in), the absolute smallest output, or identical behavior across every browser, and users tolerate the wait.
• Choose both — which is what we actually did. WebCodecs is the fast path; ffmpeg.wasm or a server is the fallback.

Our video compressor uses WebCodecs where available and degrades gracefully where it is not. The same client-side, no-upload philosophy drives our GIF maker, which turns a video segment into an optimized animation entirely in the browser. For the wider question of when to keep processing on the client versus sending it to a server, see browser vs cloud image tools; and if your end goal is simply a small enough clip to send, how to compress video for email walks through the practical targets.

Frequently Asked Questions

Is WebCodecs always faster than ffmpeg.wasm?

For encoding and decoding, almost always — it uses hardware acceleration while ffmpeg.wasm runs software encoding in a WASM VM at roughly 60% of native CPU speed. The exception is niche operations WebCodecs does not expose, where software is your only option.

Can I use WebCodecs in Firefox?

Yes. Firefox has supported both decoding and encoding since Firefox 130 (September 2024), enabled by default with no flag, so WebCodecs works there as of 2026. The one exception is Firefox for Android, which still lacks VideoEncoder — a case where an ffmpeg.wasm or server-side fallback still helps.

Why is my ffmpeg.wasm file sometimes smaller than the WebCodecs one?

Software encoders like libx264 optimize harder for compression efficiency, while hardware encoders prioritize speed. At a matched quality target, software can produce a file 5-15% smaller — you pay for that with encode time.

Do I still need ffmpeg.wasm at all?

Yes, for breadth: unusual input formats, complex audio handling, subtitle burn-in, or guaranteed cross-browser behavior. Many production tools ship both and route to WebCodecs first.

Does WebCodecs upload my video anywhere?

No. Both WebCodecs and ffmpeg.wasm run entirely in the browser, so the video never leaves the device. That privacy property is a big reason client-side processing is worth the engineering effort.

Related tools

• Video Compressor — powered by WebCodecs