MP4 to WebM: When Smaller Files Are Worth the Encode

WebM exists for a reason that has nothing to do with quality: H.264, the codec inside almost every MP4, is patent-encumbered. WebM pairs VP9 video with Opus audio, both royalty-free, and that was the whole point when Google published it.

The practical reason to care is file size. At the same visual quality, a VP9 file is usually somewhere between a fifth and a third smaller than the H.264 equivalent. On a video that plays on every page load, that is bandwidth you stop paying for on every single view.

When it is worth it

Video you host yourself. If you pay for the bandwidth, a 25% reduction compounds with every visitor. A background video or a hero loop is the clearest case: it autoplays, everyone loads it, and nobody is scrutinising the pixels.

Anything shipping in a commercial product. H.264's licensing is a question you have to answer. VP9's is not.

Pages you are trying to make faster. Less to download is less to wait for, and video is usually the heaviest thing on a page by an order of magnitude.

When MP4 is still the right answer

When it has to play on absolutely anything. Every current browser handles WebM, but Safari was last to support it and remains the weakest implementation. If your audience includes older iPhones, or hardware you cannot enumerate, H.264 in MP4 is the safer primary.

When you are handing the file to someone else. Editors, presentation software and smart TVs expect MP4. WebM is a web delivery format, and it is worth being literal about that.

The good news is that this is not actually a choice. The HTML video element accepts more than one source: list the WebM first with a type of video/webm, then the MP4 with a type of video/mp4, and the browser picks for you.

Browsers take the first source they can play. Chrome and Firefox get the smaller file; anything that cannot handle WebM falls through to the MP4. You serve less data to most people and break nothing for the rest.

The part nobody mentions

VP9 is slow to encode. Not slightly — several times slower than H.264 for the same clip. That is a property of the codec, not of any particular tool, and it is the reason WebM conversion feels broken the first time you try it on a long file.

In a browser it is slower still, because the work runs on your own processor instead of a rented server. A ten-second clip is quick. A twenty-minute 1080p recording is a genuine wait, and you should start it and leave the tab open rather than watch it.

One other thing worth knowing: converting is a re-encode, not a repackage. Your MP4 is already compressed, so going to WebM decodes it and compresses it again with a different codec. That is one generation of loss. At sensible settings it is not visible, but it is real, and it is why you should convert from the highest-quality source you have rather than from something already squeezed.

Doing it

The MP4 to WebM Converter runs FFmpeg compiled to WebAssembly, so the file is processed in your browser and never uploaded. Quality is set by constant-quality CRF rather than a bitrate target, which means the file comes out as small as that quality level allows instead of being padded to hit a number.

If you need the opposite direction — a WebM that something refuses to open — WebM to MP4 is the same encoder pointed the other way. And if the file is simply too big before you start thinking about codecs, the Video Compressor is the faster thing to try first.