Every modern computer has a hardware video decoder and encoder built into its chip - the block of silicon that makes 4K video on your phone battery-friendly, and that makes recording Zoom calls at 1080p not melt your laptop. For years browsers had no way to talk to that hardware directly. Web-based video tools had to either upload files to a server (which had ffmpeg) or run a WebAssembly copy of ffmpeg locally (much slower than the hardware). WebCodecs changed that.

#The one-sentence version

WebCodecs is a JavaScript API in the browser that lets a web page use the operating system's built-in video codec hardware directly - the same hardware that plays YouTube and encodes your Zoom calls. It shipped in Chrome 94 (October 2021), Edge, Opera, Safari 16.4 (March 2023), and is still catching up in Firefox as of 2026.

#Why it matters for in-browser video conversion

Before WebCodecs, converting a video in a web page meant one of two things:

  • Upload to a server. Send your file to someone else's computer, wait for their ffmpeg to run, download the result. Fast conversion but slow round trip, and the whole point is that a stranger holds your video.
  • WebAssembly ffmpeg. Compile ffmpeg to run in the browser tab itself. Files never leave your device, but the "wasm" version of ffmpeg runs in a single thread without hardware acceleration - so a 5-minute 1080p conversion might take 10-15 minutes on a modern laptop.

WebCodecs added a third path: the browser hands the compressed video frames to your device's hardware decoder, which produces raw pixels in milliseconds; those pixels go to the hardware encoder, which produces new compressed frames just as fast. A 5-minute conversion that took 10-15 minutes in wasm-ffmpeg finishes in 30-90 seconds through WebCodecs. On the same laptop, on the same file, in the same browser tab. Same physics as the software ran; the hardware is much faster at it.

#What WebCodecs actually is (the API)

Technically, WebCodecs is a set of JavaScript classes:

  • VideoEncoder and VideoDecoder for video codec work
  • AudioEncoder and AudioDecoder for audio
  • VideoFrame for representing a single frame of raw pixels
  • Related helpers for describing codec configurations

The browser lists the codecs its underlying hardware supports (typically H.264 always, HEVC on Apple silicon and modern Intel/AMD, VP9 universally, AV1 on 2022+ hardware). Web pages that use the API can encode and decode any of those without an install, without a server, and at hardware speeds.

#Where Wave uses it

Wave has three encoding paths, in preference order:

  1. WebCodecs H.264 encoder when the browser exposes it. This is the fast lane - hardware-accelerated on almost every modern machine, roughly 2-10x realtime for 1080p sources. Chrome, Edge, Safari 16.4+, and every Chromium-based mobile browser take this path.
  2. WebAssembly ffmpeg with the LGPL MPEG-4 encoder when WebCodecs isn't available. This is the fallback: it still runs entirely in the browser, but slower (roughly 5-10x realtime for 1080p on modern hardware) and produces MPEG-4 Part 2 video instead of H.264. The MP4 plays in VLC and desktop players but not in mobile browsers, so Wave warns you when this branch fires.
  3. No encoder at all - remux when the source is already in an MP4-compatible format (see Remux vs re-encode). This is faster than any encoding path because nothing gets encoded - the compressed bytes are copied through untouched.

Because libx264 is GPL-licensed, and bundling it into a web app would put the whole app under GPL - which conflicts with Wave's licensing choice. WebCodecs sidesteps this: the browser's H.264 encoder ships as part of the OS, not the app, so no licensing entanglement. And in exchange the encoder is hardware-accelerated and orders of magnitude faster than a wasm-compiled libx264 would be anyway.

#The trade-offs vs. server-side ffmpeg

  • WebCodecs advantages: No upload (files never leave the tab), no server cost, no queue wait, hardware speed. Privacy is intrinsic - not a promise, just a property of the design.
  • Server ffmpeg advantages: Full featureset (Wave's WebCodecs pipeline doesn't expose every ffmpeg filter yet), massive files (8 GB Wave limit vs. no practical limit server-side), batch processing.

For the "convert this file to MP4" case that Wave targets, WebCodecs wins on every axis that matters. For a workflow that needs custom filters or multi-file batching, server-side ffmpeg is still the right tool.

#Browser support summary (2026)

  • Chrome, Edge, Opera: Full WebCodecs including H.264 encode. Started in Chrome 94 (Oct 2021).
  • Safari (macOS, iOS): Full WebCodecs from Safari 16.4 (March 2023). Uses VideoToolbox for hardware.
  • Firefox: Partial WebCodecs (decode yes, encode still limited as of 2026). Wave falls back to the wasm MPEG-4 path here.
  • Mobile Chromium browsers: Same as desktop Chromium - full WebCodecs.

#The takeaway

WebCodecs is the browser API that lets in-browser video conversion actually be fast. Wave uses it as the primary encoding path; the wasm ffmpeg fallback exists for browsers without it. If your browser is anything Chromium-based or Safari 16.4+, your conversions land in seconds; on older browsers or Firefox, they land in minutes and use a slightly less compatible codec. Either way the file never leaves your device - the WebCodecs vs wasm choice affects speed, not privacy.