MP4 vs WebM: Licensing, Support and File Size
By Andrew Butson · July 2, 2026 · 6 min read
MP4 is still the format to reach for when a video needs to work absolutely everywhere — every phone, TV, editor and upload form recognises it. WebM earns its place specifically on the open web: it's royalty-free, and its usual codecs, VP9 and AV1, compress harder than MP4's usual H.264 at the same visual quality. That size advantage comes from the codec inside, not the container itself, which is why the honest way to think about this pair is 'H.264 versus VP9/AV1' as much as 'MP4 versus WebM.'
MP4 and WebM look like a simple 'old versus new' choice, but the real story underneath is about codecs and who controls them. MP4 became the universal container because it was built around H.264, a codec every device manufacturer eventually licensed and put into hardware. WebM exists because Google and the wider web wanted a video format nobody had to pay patent royalties to use, so it was built from the ground up around royalty-free codecs instead.
This page covers that licensing story, why browser-native support and hardware decoding are two different things that don't always line up, and why 'WebM is smaller' is really a statement about codecs, not containers.
| MP4 | WebM | |
|---|---|---|
| Origin | ISO/MPEG standard (2001) | Google, built for the open web (2010) |
| Typical video codec | H.264, increasingly H.265 | VP9, increasingly AV1 |
| Typical audio codec | AAC | Opus or Vorbis |
| Licensing | H.264/AAC sit under patent pools; device makers pay royalties | VP9/AV1 and Opus are royalty-free, open codecs |
| Browser support | Universal, including very old browsers | Universal in modern browsers; missing from very old ones |
| Hardware decoding | Near-ubiquitous dedicated chips in phones, TVs, set-top boxes | Improving, but many older phones, TVs and set-top boxes lack it |
| File size at equal quality | Larger: H.264 is the less efficient of the two | Smaller, since VP9/AV1 compress harder at the same visual quality |
| Editing software support | Near-universal across NLEs | Limited outside a handful of editors |
| Best for | Sharing, uploading, universal playback off the web | Serving video on your own site or app to modern browsers |
Two containers, two very different codec families
A container is just the box — the part that bundles a video track, an audio track and metadata together. MP4 almost always wraps H.264, occasionally the newer H.265, with AAC audio. WebM was deliberately built as a narrower, web-only box: it only ever carries VP8, VP9 or AV1 video, paired with Vorbis or Opus audio. That narrowness is a deliberate design choice, not a limitation: it keeps WebM tightly focused on codecs the web can use without licensing complications.
The licensing story: why WebM exists at all
H.264 and AAC, the codecs behind almost every MP4, are covered by patent pools: companies that build hardware decoders, and in some cases services that stream enough video, pay licensing fees to use them. That has never stopped H.264 from becoming universal, since the fees are baked into device and software prices most people never see. It did, however, bother a web built on open standards that anyone can implement without a licence. Google released VP8, and later VP9, as royalty-free codecs specifically so browsers could support high-quality video without that patent overhead, then donated the format to become WebM. AV1 continued that mission with a broader industry coalition behind it, and Opus did the same job for audio. WebM, in short, exists because the web wanted a video format nobody has to pay to use.
Browser-native doesn't mean hardware-native
Every modern browser plays WebM without a plugin, which makes it easy to assume support is total. But playing a codec in software and decoding it in dedicated hardware are different things, and this is where WebM's story gets more complicated: a phone's chip built specifically to decode H.264 sips almost no battery doing it, while decoding VP9 or AV1 without matching hardware support falls back to the CPU, draining battery and generating heat faster on longer clips. Hardware AV1 decoding in particular is still rolling out — recent flagship phones and TVs have it, but plenty of everyday devices, especially older or budget ones, don't. H.264 hardware decoding, by contrast, has been standard in silicon for well over a decade. So a WebM file might play everywhere a browser exists, while genuinely straining the battery or CPU on hardware an equivalent MP4 would sail through effortlessly.
'WebM is smaller' is a codec claim, not a container claim
It's worth being precise here: nothing about the WebM container itself makes a file smaller. The size advantage people notice comes entirely from the codecs WebM typically carries — VP9 and AV1 are simply more efficient at compressing video than H.264 is, squeezing more visual quality out of fewer bytes at any given bitrate. You could, in principle, get an MP4 just as small by encoding H.265 or AV1 inside it instead of H.264; the container doesn't forbid it. In practice almost nobody does that, because H.264-in-MP4 is chosen precisely for its universal compatibility, and the moment you reach for a more efficient codec you're trading some of that compatibility away, whichever container you put it in.
What Morphr actually does with this pair
Morphr converts WebM to MP4 — decoding the VP9 or AV1 video and re-encoding it fresh as H.264 (libx264, CRF 23) so the result plays on hardware that has no VP9 or AV1 decoder at all, entirely in your browser with nothing uploaded. It's a genuine transcode rather than a quick repackage, so it takes real time on a longer or higher-resolution clip and, being lossy-to-lossy, involves a fresh generation of compression. The reverse direction, MP4 to WebM, isn't offered: encoding VP9 inside a browser turned out to be too slow and unreliable to ship responsibly, so Morphr sticks to the direction it can do quickly and dependably.
Reach for MP4 when…
- You're editing in desktop software, most of which expects H.264 in MP4.
- The video needs to play on older phones, TVs or set-top boxes with no VP9/AV1 hardware decoder.
- You're sharing or uploading somewhere that doesn't specifically ask for WebM.
- Battery life matters and the audience is on mixed, possibly older hardware.
Reach for WebM when…
- You're serving video from your own website or web app to a modern-browser audience.
- Bandwidth or storage cost matters and every byte saved helps.
- Royalty-free licensing matters for your project or organisation.
- You need short, muted, autoplaying background clips where size trumps universal playback.
Morphr re-encodes your WebM to H.264 MP4 entirely on your device — nothing uploaded, nothing stored, and no account needed.
Runs entirely in your browser — nothing is uploaded.
Frequently asked questions
- Is WebM actually smaller than MP4?
- Usually, yes, but because of the codec inside rather than the container — VP9 and AV1 compress more efficiently than the H.264 that MP4 typically carries. An MP4 built around H.265 or AV1 instead could match it, but almost nobody builds MP4 files that way.
- Why won't my WebM file play on some devices?
- Every modern browser plays WebM, but plenty of older phones, smart TVs, set-top boxes and desktop editors were built around H.264/MP4 and never added solid WebM support, or lack a hardware decoder for VP9/AV1. Converting to MP4 sidesteps that inconsistency.
- Can Morphr convert MP4 to WebM?
- Not currently — encoding VP9 inside a browser proved too slow and unreliable to offer. Morphr converts the other direction, WebM to MP4, which is the far more common need when a file needs to play outside a browser.
- Does WebM support H.265 or HEVC?
- No. WebM is deliberately restricted to VP8, VP9 and AV1 for video, and Vorbis or Opus for audio — that narrow, royalty-free codec list is the whole point of the format.