Convert MP4 to WebM on Mac (There Is No Shortcut)

No. We tried, because the container swap is the right answer for MOV to MP4 and it is reasonable to assume it carries over:

$ ffmpeg -i input.mp4 -c copy output.webm
[webm @ 0x…] Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and
             WebVTT subtitles are supported for WebM.
[out#0/webm @ 0x…] Could not write header (incorrect codec parameters ?):
             Invalid argument
Conversion failed!

That error message is the WebM format in one sentence. WebM is a deliberately restricted subset of Matroska that admits three video codecs and two audio codecs, and H.264 and AAC, which is what nearly every MP4 carries, are on neither list. ffmpeg also left a 264-byte output.webm behind, so a script that only checks whether the file exists will report a success that did not happen.

Compare MOV to MP4, where a stream copy is bit-for-bit identical because both containers accept H.264. Here the codec itself has to change, and a codec change is a real encode with a real quality decision attached.

Every row started from the same 8-second 1280×720 MP4: H.264 at CRF 23 plus 128 kbps AAC, 640,361 bytes. Quality is VMAF measured against the lossless master that MP4 was cut from, so the MP4 itself scores 99.17 and nothing made from it can beat that.

The AV1 row is the interesting one. It is smaller than either VP9 file, scores higher than VP9 at CRF 40, and it was the cheapest to make: 6.95 CPU-seconds against 24.60 for VP9 at CRF 32 and 19.66 at CRF 40. The catch is playback, covered below. VP9 is the conservative choice, because every current browser that plays WebM also plays VP9.

The two commands, with the flags that matter:

# VP9: -b:v 0 is what switches on constant-quality mode
ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 32 -b:v 0 -row-mt 1 \
  -c:a libopus -b:a 96k output.webm

# AV1 through SVT-AV1: CRF 0-63, preset trades speed for size
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 55 -preset 8 \
  -c:a libopus -b:a 96k output.webm

Do not drop -b:v 0. ffmpeg’s VP9 guide is explicit that constant-quality mode needs -crf and -b:v 0 together, and that leaving the bitrate out switches libvpx into a constrained mode instead. The same guide puts the useful VP9 range at CRF 15–35 and suggests 31 for 1080p. And never carry a CRF number from one encoder to another: SVT-AV1 at CRF 55 outscored VP9 at CRF 40 on the same clip.

It is not the container. WebM and MP4 wrap the same kind of data with a few hundred bytes of different bookkeeping. The saving comes from the codecs WebM forces you onto. VP9 and AV1 are newer than H.264, with much larger coding blocks (64×64 and up to 128×128 against H.264’s 16×16 macroblocks) and more ways to predict one block from another, so at the same measured quality they spend fewer bytes.

To measure the codecs rather than the source, these were encoded straight from the lossless master, video only, and scored against it:

At matched quality VP9 saved 19–28% and AV1 roughly half at the top tier. Two cautions before you quote those numbers. This is one easy clip, a slow pan across a photograph, and grain, fast motion and dark scenes all move the results. And when your starting point is an MP4 that is already compressed, conversion stacks a second generation of loss on the first, which is why every row in the route table lands below the source’s 99.17.

In Safari, yes, with conditions. In QuickTime Player, no.

According to caniuse’s compatibility data (read 27 September 2026), Safari has fully supported WebM since version 16.0, versions 14.1 to 15.6 supported it on macOS 11.3 or later, and iOS Safari got there in 17.4. Chrome, Firefox and Edge have played it for years. The same data carries two caveats: Safari does not support WebM’s alpha transparency, and AV1 in Safari 17 and later works only on devices with a hardware AV1 decoder, which caniuse illustrates with the iPhone 15 Pro and M3 MacBook Pro.

QuickTime Player does not use Safari’s media code. macOS ships avmediainfo, which reads files through AVFoundation, the framework QuickTime is built on. On macOS 27 it could not open our WebM at all: Failed to load asset. Rewrapped into an MP4, the VP9 track reported System support for decoding this track: No, and so did an AV1 track on this M2 Pro. For a web page that is irrelevant. For a file someone will double-click, it is the whole story, and the reverse conversion is where they will end up.

<video controls playsinline>
  <source src="clip.webm" type='video/webm; codecs="vp9, opus"'>
  <source src="clip.mp4"  type='video/mp4; codecs="avc1.64001F, mp4a.40.2"'>
</video>

Those codec strings match the test files: avc1.64001F is H.264 High profile at level 3.1, which is what x264 wrote for this 720p clip. For an AV1 WebM, SVT-AV1 wrote Main profile at level 3.1, which is codecs="av01.0.05M.08, opus". Put that source first and browsers without AV1 decoding fall through to the next one.

It encodes VP9 at CRF 18 with 160 kbps Opus, and those settings are fixed. On this clip that meant 98.98 VMAF and a WebM 62.8% larger than the MP4 it came from.

To check that like was being compared with like, we ran ffmpeg with exactly those flags. The output was the same 1,042,476 bytes with identical video and audio stream hashes. Smol’s WebM conversion is ffmpeg 8.1.1 and libvpx at those settings, so you are not buying a different encoder. We then set Smol’s video quality to its lowest tier and converted again: same hashes. The conversion path does not take a CRF, so we could not run Smol at CRF 32 or 40 to match the smaller rows above, and the comparison in the route table is between different settings, which is the point of it.

For a web page that is the wrong trade. People convert to WebM to save bytes, and this route spends them. Where it does fit:

• A platform that demands WebM and you want it to look like the source. 98.98 against the MP4’s own 99.17 is about as close as a second generation gets.
• Mixed folders. MOV, MKV, MP4 and AVI in one drop, one output. Smol reads AVI; it writes only mp4 mov webm mkv.
• Finder, not Terminal. A right-click Quick Action for someone who will never type a CRF.

The full format reference lists every output, and Smol is $29 once.

For web delivery, which is most of the reason anyone wants a WebM, use ffmpeg. It is free, it installs with brew install ffmpeg, and it lets you choose the CRF that the tables above show is the entire decision. If you want a window instead of a command, HandBrake’s documentation lists WebM as one of its three output formats alongside MP4 and MKV, and it is free too.

It is also worth asking whether you need WebM at all. If the goal is a smaller file that plays everywhere, including QuickTime and every phone, re-encoding the MP4 as a smaller MP4 keeps the compatibility and still takes a real bite out of the size. The Mac video compression routes are compared here. And if you are the one holding a WebM that will not open, WebM to MP4 has its own trap: the remux works and the file still will not play.

MacBook Pro (Mac14,9), Apple M2 Pro, 10 cores, 16 GB, macOS 27.0 (26A428). ffmpeg 8.1.1 with libvpx-vp9, SVT-AV1 and libvmaf; Smol 1.0.34, whose bundled ffmpeg is also 8.1.1. VMAF is libvmaf’s default model over all 240 frames, paired by frame index. CPU times are user plus system time from /usr/bin/time. We did not use wall-clock times, because the machine was running other jobs during testing and stopwatch numbers were not repeatable.

The master was generated for this article: an 8-second 1280×720, 30 fps pan across DefaultAerial.jpg, the 4096×2160 wallpaper that ships with macOS in /System/Library/Wallpapers, encoded losslessly with x264 and a 440 Hz test tone for audio. The test MP4 was cut from it at x264 CRF 23 with 128 kbps AAC. No camera footage and no personal files were used, and every fixture was deleted afterwards.