FFmpeg.wasm vs WebCodecs: Picking the Right Tool in 2026
Side-by-side benchmarks, codec coverage, and the cases where combining WebCodecs decode with FFmpeg.wasm filtering beats either alone.
FFmpeg.wasm vs WebCodecs: Picking the Right Tool in 2026
"Just use FFmpeg.wasm" used to be the correct answer for any browser video task. It is not anymore, and it is also not wrong. Here is how the two actually compare in 2026, with numbers from a real laptop instead of a cherry-picked benchmark rig.
The one-line summary
WebCodecs is faster because it uses the GPU's dedicated media block. FFmpeg.wasm is more capable because it's a full build of FFmpeg. The interesting question is which matters for your workload.
Head-to-head benchmarks
Test rig: MacBook Air M2, 16 GB RAM, Chrome 140, 80 percent battery, thermal throttling disabled (plugged in). Source: BigBuckBunny_1080p30_H264.mp4, 10 minutes, 632 MB.
Task 1: H.264 1080p → AV1 1080p, target 2 Mbps
| Tool | Wall time | Peak CPU | Peak memory |
|---|---|---|---|
| FFmpeg.wasm 0.12 (libsvtav1 preset 8) | 28 min 14 s | 780% | 2.1 GB |
| WebCodecs (HW AV1 encode) | 1 min 47 s | 210% | 380 MB |
WebCodecs wins by roughly 15x. Quality is comparable — VMAF 92.1 for WebCodecs, 92.7 for FFmpeg.wasm at the same bitrate.
Task 2: H.264 1080p → H.264 720p, crop top 100 px, burn subtitle track
| Tool | Wall time | Notes |
|---|---|---|
| FFmpeg.wasm (libx264 medium) | 6 min 22 s | Handles everything in one graph |
| WebCodecs alone | N/A | No filter graph, no subtitle burn |
| WebCodecs decode + Canvas filters + WebCodecs encode | 4 min 11 s | Subtitle burn via OffscreenCanvas |
WebCodecs plus manual filtering wins on wall time, but it took about 180 lines of extra code to do what ffmpeg -vf "crop=...,subtitles=..." does in one string.
Task 3: MKV with FLAC audio → MP4 with AAC
| Tool | Wall time | Result |
|---|---|---|
| FFmpeg.wasm | 2 min 48 s | Works |
| WebCodecs | — | No MKV demux, no FLAC decode, no AAC encode on all platforms |
This is the case where WebCodecs just cannot help. MKV is outside its world.
Codec coverage
| Codec family | FFmpeg.wasm | WebCodecs |
|---|---|---|
| H.264 | Yes | Yes |
| HEVC | Yes (decode; encode needs licensed build) | Decode everywhere, encode on macOS/iOS and Windows with HEVC extension |
| VP9 | Yes | Yes |
| AV1 | Yes (svt-av1, aom) | Yes (hardware where available) |
| ProRes | Yes | No |
| DNxHR | Yes | No |
| VVC (H.266) | Yes (VVdeC) | No |
| AAC | Yes | Yes |
| Opus | Yes | Yes |
| FLAC | Yes | Decode only, on Chromium |
| AC-3/EAC-3 | Yes | No |
FFmpeg.wasm carries the whole zoo. WebCodecs carries what the OS has shipped a codec for.
Binary size
FFmpeg.wasm 0.12 core is around 31 MB uncompressed, 8.4 MB brotli. You pay that on first visit. WebCodecs is a browser API with zero download cost. For a conversion tool that wants fast time-to-first-conversion on a phone over cellular, that 8 MB matters.
Memory ceiling
WASM is 32-bit, so FFmpeg.wasm is hard-capped at 4 GB addressable memory. In practice you run out of room around 2 GB of in-flight video buffers, which is about a 30-minute 4K clip uncompressed. Long 4K content either needs chunking or needs to move to WebCodecs, which streams frames through hardware without buffering the decoded video.
The combined pipeline
The most interesting pattern in 2026 is using both, chosen per-segment:
- Demux with
mp4box.jsorffmpeg.wasm(depending on container). - Decode with WebCodecs if the codec is supported in hardware; otherwise FFmpeg.wasm.
- Apply filters with WebGL/WebGPU shaders or, for complex filter graphs, FFmpeg.wasm.
- Encode with WebCodecs where possible, FFmpeg.wasm otherwise.
- Mux with a dedicated muxer library (
webm-muxer,mp4-muxer) to keep the output path simple.
This is roughly what ships in the Konvrt converter today. H.264-to-AV1 and MP4-to-WebM go through WebCodecs. MKV, ProRes, DNxHR, and anything with filter-graph requirements route to FFmpeg.wasm. The user doesn't know which path ran — they just see the progress bar.
Decision rules
Pick WebCodecs when: you control the source and target formats, they are common codecs in MP4 or WebM, and you want speed and low CPU.
Pick FFmpeg.wasm when: unknown or messy input formats, complex filter graphs, lossless audio formats, or any task a 20-year-old FFmpeg command line would solve in one pipe.
Pick both when you're building a general-purpose converter and want the fast path to stay fast without giving up on the long tail.
If you specifically want the WebCodecs-only deep dive, there's a companion piece at the WebCodecs post. For codec choice itself, see AV1 vs HEVC vs VP9.