Convert MP4 to WebM
Convert an MP4 into a WebM encoded with VP9 and Opus. This is a conversion for people serving video from their own site rather than for people trying to play a file: WebM is royalty-free and usually smaller than H.264 at the same visible quality, which matters when you are paying for the bandwidth and the visitor is waiting for it to load.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your MP4 file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- VP9 video and Opus audio
- Royalty-free — no patent licensing to consider
- Usually smaller than H.264 at the same quality
- No watermark and no sign-up
How to use MP4 to WebM
- 1
Add the MP4
Drop the file in or choose it from your computer, up to 50 MB, no account needed.
- 2
Convert
The video is re-encoded to VP9 and the audio to Opus inside a WebM container. This is slower than converting to MP4.
- 3
Serve both
Offer the WebM and the MP4 together in a video tag and let each browser choose the one it supports.
A conversion for publishers, not viewers
Most format conversions solve a playback problem: a file will not open and a different container fixes it. This one does not. An MP4 plays on everything, and converting it to WebM makes it play on slightly less.
The reason to do it is that you are the one serving the file. WebM was created by Google in 2010 as an open, royalty-free format at a time when H.264 carried patent licensing that was a genuine obstacle for anyone shipping an encoder or distributing large volumes of video. Its current codec, VP9, generally reaches the same visible quality as H.264 in appreciably fewer bytes.
If you are paying for bandwidth, or a visitor is waiting for a background video before your page settles, those bytes are the whole argument.
How it works
The video is re-encoded to VP9 and the audio to Opus, inside a WebM container. Both are full re-encodes — nothing is repackaged — so the conversion takes real time and costs the small amount of quality any re-encode costs.
VP9 encoding is substantially more expensive than H.264, and the settings here are chosen so that a conversion finishes rather than to squeeze out the last few percent of file size. A patient desktop encode will produce a smaller file.
Serve both, do not replace
The right pattern is not to choose. An HTML video element takes several sources and the browser plays the first it supports:
Offer the WebM first and the MP4 second. Modern browsers take the smaller file; anything older, and some devices with hardware H.264 decoding and no VP9, fall back to the MP4 and still work. Replacing the MP4 outright saves storage and costs you the visitors who needed it.
Where WebM is the wrong answer
If the file is going to a person rather than onto a page — emailed to a colleague, handed over on a memory stick, uploaded to a platform that will re-encode it anyway — send the MP4. Hardware support for H.264 is universal in a way VP9's is not, and the smaller file buys nothing once it has arrived.
Examples
A background clip for a landing page
Autoplaying background video is where file size is felt most directly, because the visitor waits for it before the page settles.
A short demo served from your own site
Serving WebM alongside MP4 in a video tag lets browsers pick, and most modern ones will take the smaller file.
Frequently asked questions
Is WebM better than MP4?
For serving video from a website, usually yes. VP9 typically achieves the same visible quality as H.264 in noticeably less data, and WebM is royalty-free where H.264 carries patent licensing that matters to anyone distributing an encoder. For playing a file on a device, MP4 wins easily, because hardware support for H.264 is universal and for VP9 is not.
Should I replace my MP4 with the WebM?
No — serve both. The HTML video element accepts several source elements and the browser picks the first it can play, so offering WebM first and MP4 as the fallback gives modern browsers the smaller file and everything else a working one. Replacing the MP4 outright means older browsers and some devices get nothing.
Why does this conversion take so long?
Because VP9 encoding is genuinely expensive, far more so than H.264. The settings used here are chosen to finish within a sensible time rather than to reach the smallest possible file, so a slow desktop encode with ffmpeg will beat this on size. For a file you are going to serve thousands of times, that extra effort is usually worth spending once.
What about AV1?
AV1 is the successor to VP9 and compresses better again, and browser support is now broad. It is not offered here because encoding it well is dramatically slower than VP9 — enough that it does not fit the time budget of a web conversion. For a file that matters, encoding AV1 on a desktop machine overnight is the better route.
Further reading
- The Same Clip Was Four Times Bigger as a GIF, at Fewer FramesConverting a video to a GIF feels like a downgrade, so the file should get smaller. It gets much bigger. The clip we measured quadrupled while losing four frames in every ten, and the reason is that a GIF has no idea what a video codec knows.
- Base64 Adds Exactly a Third, Whatever You Put Into ItBase64 has a reputation for making files bigger, and people are vague about by how much. It is exactly a third, every time, for every kind of data — and the reason it is exact is more useful to know than the number.