Convert WebM to MP4 on Mac (and Get QuickTime to Play It)

Because the framework QuickTime is built on, AVFoundation, has no WebM reader and no VP9 decoder it will use. You can ask it directly: macOS ships avmediainfo, which opens files exactly the way QuickTime does and reports, track by track, whether the system can decode them.

The confusing part is that Safari plays the same WebM. Safari does its own WebM handling inside WebKit, and caniuse’s data (read 27 September 2026) lists full WebM support from Safari 16.0. None of that reaches QuickTime Player, or anything else that opens video through AVFoundation. If you only need to watch the file once, drag it into a Safari window and skip the conversion.

Renaming changes nothing: the bytes are still Matroska. Remuxing is a real operation and, unlike the reverse direction, ffmpeg allows it, because MP4 has registered entries for both VP9 and Opus:

ffmpeg -i input.webm -c copy output.mp4
# 0.04 s, 478,579 -> 482,387 bytes, streams untouched

It is a valid MP4 and the table above shows the result. The audio decodes, the video does not. The same thing happened with an AV1 WebM on this M2 Pro. So for a Mac, the video always has to be re-encoded, and the question is only which codec you encode to.

One half of the file can be left alone. macOS 27 reported that it can decode Opus inside an MP4, so -c:a copy works for Mac playback. We still re-encode audio to AAC in every command below, because AAC in MP4 is the pairing other devices and editors expect.

Every row started from the same 8-second 1280×720 WebM (VP9 plus 128 kbps Opus, 478,579 bytes). Quality is VMAF against the lossless master the WebM was made from, so the WebM scores 98.54 and nothing downstream can beat it. “Plays” means avmediainfo reported both tracks decodable.

The H.264 file is two-thirds bigger than the WebM, and that is normal. VP9 simply needs fewer bytes than H.264 for the same picture; we measured the gap at 19–28% going the other way, from MP4 to WebM, and a re-encode has to spend extra again to avoid stacking visible artifacts on the ones already there. HEVC is the codec of VP9’s generation that Apple decodes, which is why it came in under the WebM’s size.

Cost differed too. The stream copy took 0.03 CPU-seconds, x264 at CRF 23 took 6.43, x265 took 11.18, and VideoToolbox took 0.50, because the Mac’s media engine did the encoding. That speed is real and so is the price: the largest file on the table and the lowest score. Use it for a quick preview, not a keeper.

Almost certainly a four-letter label. HEVC in MP4 can be tagged hvc1 or hev1, and ffmpeg writes hev1 for x265 unless told otherwise. We checked: its default tag was hev1, and avmediainfo reported that track as undecodable. Rewriting the same stream with the hvc1 tag, no re-encode, turned the answer to Yes.

ffmpeg -i input.webm -c:v libx265 -crf 26 -tag:v hvc1 \
  -c:a aac -b:a 128k -movflags +faststart output.mp4

That is the command for an MP4 that stays close to the WebM’s size and plays on any Apple device. If the file is headed for a PC or an unknown editor, use the H.264 command from the top of the page instead; it is larger and it opens everywhere.

It has two routes, and for this job the difference matters.

Convert to MP4 always writes a real MP4: H.264 at CRF 18 with 192 kbps AAC. Those settings are fixed. We ran ffmpeg with exactly those flags and got a byte-identical file, and setting Smol’s video quality to its lowest tier changed nothing, byte for byte. The result plays anywhere and scored 98.09 against the WebM’s 98.54, the closest of any re-encode here, at 184% more bytes. Safe, and large.

Compress takes a CRF and defaults to HEVC with the hvc1 tag already set. Pinned to CRF 26 it matched ffmpeg run with the same flags stream for stream, and produced a playable 419,745-byte MP4, 12.3% smaller than the WebM. Left on defaults it first tried CRF 24, found the result bigger than the source, and retried at CRF 28: 370,660 bytes at VMAF 94.34.

Where Smol earns its place is a folder of mixed downloads, WebM, MKV and AVI together, turned into MP4s from a Finder right-click with no flags to remember. The format reference lists every output, and Smol is $29 once.

More often than for most conversions, honestly.

• You only want to watch it. Safari plays WebM. Converting a file you will watch once is wasted effort.
• One file, and you want it small. The x265 command above, with -tag:v hvc1, is free and gave the smallest playable MP4 we made.
• You want a window, not a Terminal. HandBrake reads WebM, writes MP4 and costs nothing.
• You control the download. Ask for MP4 at the source, as in the yt-dlp note above.

Going the other way, for a website, is a different problem with the same lesson: MP4 to WebM cannot be remuxed at all. For other containers, MKV to MP4 and MOV to MP4 often can be, losslessly. And if the MP4 you end up with is too big to send, the compression routes are compared here.

MacBook Pro (Mac14,9), Apple M2 Pro, 10 cores, 16 GB, macOS 27.0 (26A428). ffmpeg 8.1.1 with libx264, libx265, libvpx-vp9, VideoToolbox and libvmaf; Smol 1.0.34. Decode support was read from /usr/bin/avmediainfo. VMAF is libvmaf’s default model over all 240 frames, paired by index, against a lossless master. CPU times are user plus system time from /usr/bin/time; wall-clock times were not used because other jobs were running on the machine during testing.

The test WebM was generated for this article from an 8-second 1280×720 pan across the DefaultAerial wallpaper that ships with macOS, encoded to VP9 at CRF 36 with 128 kbps Opus and a 440 Hz test tone. Nothing was downloaded from a video site, no personal files were used, and every fixture was deleted afterwards.