Open a video in Chrome. It plays. Save the file, open it in Windows Media Player, and it might not. This is the MP4 vs WebM story in one sentence: they play interchangeably in the one place where the video stack is homogeneous - the browser - and the resemblance ends the moment the file leaves that tab.
#The short version
MP4 is a container spec run by MPEG (a standards body dominated by patent holders). WebM is a container spec run by Google (a company that wanted a royalty-free alternative and could afford to ship one). Inside MP4 you usually get H.264 video and AAC audio - codecs that require patent licences to encode and, in some jurisdictions, to decode. Inside WebM you get VP8, VP9, or AV1 video with Opus or Vorbis audio - all royalty-free. On Chrome, Firefox, and Edge, both containers play. On iOS Safari, macOS QuickTime, Windows Media Player, most smart TVs, and virtually every consumer hardware decoder, only MP4 plays.
#Why WebM exists
Google bought On2 in 2010 for $124M, primarily for the VP8 video codec, and released VP8 and the WebM container as royalty-free open specifications the same year. The strategic goal was straightforward: YouTube streams billions of video-hours a month, and every one of those H.264 decodes cost MPEG-LA licence fees baked into the chipset. If Google could ship a codec Chrome would decode natively and encoders were free to bundle, YouTube could push VP8 delivery for viewers on Chrome and start eroding the H.264 monoculture. VP9 followed in 2013 with roughly 40% better efficiency than VP8, and AV1 in 2018 as the successor developed by the Alliance for Open Media (Google, Netflix, Intel, Amazon, and the browser vendors, with the patent story locked down more thoroughly).
The strategic bet worked halfway. Every browser plays VP9 and AV1 natively in 2026. YouTube delivers most of its watch-time in VP9 or AV1. But outside the browser, WebM never won: iOS never added it, Windows Media Player still refuses it, Apple never supported it, and the hardware decoders that ship in cheap smart TVs are H.264 and HEVC first with VP9 and AV1 as optional silicon that many devices skip. So the file format lives in the browser and dies at the tab boundary.
#What actually differs when you switch
The codec inside
The container difference is real but derivative. What matters is what codec is inside. MP4 accepts H.264 (universal), HEVC (universal on modern devices, patent-encumbered), AAC audio, MP3 audio, and MPEG-4 Part 2. WebM accepts VP8 (deprecated), VP9 (universal in browsers, spotty elsewhere), AV1 (universal in modern browsers, spotty elsewhere), Opus audio, and Vorbis audio. The two accepted codec sets almost don't overlap - MP4 physically can't hold VP9 or Opus, and WebM physically can't hold H.264 or AAC. That mutual exclusion is why converting between them is always a re-encode, never a container swap.
What fits inside each
- Video: H.264, HEVC, MPEG-4 Part 2, AV1
- Audio: AAC, MP3, AC-3, Opus
- Subtitles: tx3g only (styling stripped)
- Chapters: chpl / tref atoms
- Plays on: everything
- Video: VP8, VP9, AV1
- Audio: Opus, Vorbis
- Subtitles: WebVTT via container extension
- Chapters: EBML tag pairs
- Plays on: browsers, and that's it
File size for equivalent quality
At the same visual quality, VP9 is roughly 30-40% smaller than H.264 and roughly on par with HEVC. AV1 in WebM is roughly 50% smaller than H.264 and about 20% smaller than HEVC. Encoding time is the trade: AV1 encode is 10-40x slower than H.264 encode without dedicated hardware, and hardware AV1 encoders (Intel Arc, AMD RDNA 3, NVIDIA Ada) only started shipping in 2022 and are still not universal. If your bottleneck is bandwidth and you can encode once and decode many, AV1 in WebM wins. If encode speed matters or you need broad playback, H.264 in MP4 wins.
Audio
Opus is technically the best perceptual audio codec below 128 kbps that has ever shipped commercially - more efficient than AAC at every bitrate, notably better at speech, negligible latency for real-time use. It's in every Discord voice channel, every WhatsApp voice note, every Google Meet call. And every non-browser consumer video player refuses to play it. AAC is the fallback because it works everywhere, not because it sounds better.
#When to convert WebM to MP4
Almost every time you're handing the file to something that isn't a browser. The specific cases that come up:
- A downloaded YouTube clip that you want to play on iOS or share via WhatsApp. yt-dlp defaults to the best VP9 or AV1 stream, which lands as WebM. The re-encode is unavoidable for iOS playback.
- An OBS Studio recording saved to WebM. The default OBS output is MKV; recording to WebM is a choice usually made for smaller file sizes, which trades encode time for storage. See OBS recording to MP4 for the specifics of that path.
- Screen captures via the MediaRecorder API in a browser extension or web tool. MediaRecorder writes WebM because that's what the codec pipeline in the browser emits.
- Web-based video calls saved locally - Meet, some Zoom exports, some Whereby recordings. Ecosystem-dependent, but WebM is common.
In all four cases the reason to convert is the same: the video plays fine where you're holding it and refuses to play where you're trying to send it. The conversion is not an upgrade; it's a translation to the format the receiving side accepts.
#When to keep WebM
When the destination is browser-only. A landing-page hero background, an embedded product-demo loop, an in-browser tutorial video - browsers decode WebM with hardware acceleration and the files are 30-50% smaller than the equivalent H.264 MP4. That's a bandwidth win worth having if the file never leaves the <video> tag. Ship an MP4 fallback in the same <video> element for the odd Safari-quirk case (Safari added VP9 decode in 14.1 but partial Opus decode remains inconsistent), and modern browsers will pick the WebM for you.
#The takeaway
MP4 vs WebM isn't a quality question - both containers hold high-quality video and audio. It's a playback-surface question. MP4 plays everywhere; WebM plays in browsers. If your video needs to leave the browser, MP4 is the answer. If it never leaves the <video> tag, WebM is smaller and free to encode. The conversion between them is always a re-encode because the codec sets don't overlap - which is also why WebM to MP4 takes longer than MKV to MP4: MKV can remux, WebM cannot.