MP4 vs WebM

Both are wrappers. What decides size, quality and whether a file plays at all is the codec inside, and in practice the two names have come to stand for two codec families. MP4 means H.264, or increasingly H.265. WebM means VP9, or increasingly AV1.

That is the whole substance of the comparison. A WebM is smaller than an MP4 at the same visual quality — often twenty to thirty per cent for VP9 against H.264, and more for AV1 — because the codecs inside it are a generation newer. An MP4 plays on more things than any other video file in existence, because H.264 has been in hardware since 2004.

H.264 and H.265 are covered by patent pools. Anyone shipping an encoder or decoder in a product pays licence fees, and for H.265 the pools multiplied and the terms became unclear enough that a good deal of the industry declined to adopt it at all.

Google created WebM in 2010 as the way out: VP8, then VP9, then AV1 through the Alliance for Open Media, all royalty-free by design. For an ordinary person converting a holiday video, none of this is visible. For anyone building a product that encodes or serves video at scale, it is the entire argument, and it is why Netflix, YouTube and Meta already serve AV1 while the rest of the industry works out when it can.

In a browser, both work everywhere. Chrome, Firefox, Edge and Safari all play WebM and MP4, and have for years — Safari was the holdout and stopped being one.

Outside a browser the picture is entirely different. MP4 plays on televisions, media boxes, car systems, phone galleries, video editors, projectors, digital signage and the machine in the meeting room. WebM frequently does not. Send somebody a WebM as a download and there is a real chance they cannot open it; send an MP4 and there is essentially none.

Hardware decoding matters more than the file size on any device running on a battery. Phones, laptops and televisions have dedicated H.264 circuitry, so an MP4 plays with the main processor almost idle. VP9 has hardware support on most recent devices; AV1 is arriving but is far from universal.

When hardware support is missing the video is decoded in software, which is measurably worse: the device runs hot, the fan starts, and a laptop loses battery noticeably faster. A smaller file that costs more to play is not automatically the better choice for the viewer, and on an older device it is clearly the worse one.

The newer codecs buy their smaller files with arithmetic, and that arithmetic has to be done by somebody. H.264 encodes fast enough that phones do it in real time while recording. VP9 is several times slower at comparable quality, and AV1 at its better settings can take an order of magnitude longer than that.

For one holiday video this is a coffee break. For a library of a few hundred clips it is the difference between an afternoon and a week, and it is the reason streaming services encode AV1 once on server farms rather than asking anyone to do it locally. If you are converting in a browser, expect WebM to take noticeably longer than the same job into MP4.

Phones, action cameras, drones and every consumer camcorder write MP4 or MOV. WebM is a delivery format that exists for the web and is produced by encoders, not by recording hardware — there is no device in ordinary use that hands you one.

So the direction of this comparison is almost always the same in practice. Somebody has an MP4 because that is what came off the camera, and the question is whether it is worth making a WebM of it for a website. Going the other way happens when a file was downloaded from a site that served WebM, and the goal is usually to open it in an editor that will not take one.

MP4 carries timed text in a form that players and platforms have agreed on for years, so a subtitle track embedded in one generally survives being uploaded, downloaded and played elsewhere. WebM's equivalent is WebVTT inside the container, and support for reading it back is patchier than the format's age suggests.

In practice this pushes web video towards keeping subtitles outside the file entirely — a separate VTT file referenced by the page, which every browser reads and which can be edited without touching the video. That is the right answer for a website regardless of container, and it removes the question rather than answering it.

Serve both, if you can. A video element accepts several sources, the browser takes the first it understands, and putting the WebM first means modern browsers get the smaller file while everything else falls back to the MP4. That is the standard arrangement and it costs one extra encode.

If you only want one file, make it MP4. The bandwidth saving from WebM is real and the cost of a visitor seeing nothing is higher. The exception is a large, video-heavy service where the transfer bill is a genuine line item — that is exactly the situation WebM was designed for, and the one where the extra encoding pipeline pays for itself.

A WebM downloaded from somewhere and destined for anything but a browser should be converted to MP4. Editors, phones, televisions and presentation software all prefer it, and the conversion is routine.

An MP4 rarely needs to become a WebM. The two reasons are serving it on your own site and needing transparency: WebM with VP9 can carry an alpha channel and MP4 in practice cannot, which is why a transparent overlay video on a web page is a WebM. Outside those two cases, converting an MP4 to WebM makes the file smaller and less useful.

WebM carries Opus or Vorbis; MP4 carries AAC. Opus is the better codec by a clear margin at low bitrates, which matters for speech and for anything streamed on a poor connection.

The trap is that a container will not accept the wrong audio codec. Rewrapping a WebM into an MP4 without re-encoding the audio produces a file that some players reject and others play silently — the video appears and nothing is heard. If a converted file has no sound, this is almost always why, and re-encoding the audio to AAC fixes it.