Why WebM Over MP4 on the Web?
The primary reason to prefer WebM on the web is file size. At equivalent visual quality, a WebM encoded with VP9 is typically 25–35% smaller than an MP4 encoded with H.264. For a 30-second background video that loops on a homepage hero section, that difference might be 4 MB vs 6 MB — significant when you consider that every visitor downloads that file on every page load.
Smaller video files translate directly to better Core Web Vitals scores. The Largest Contentful Paint (LCP) metric is often dominated by a hero image or video. A 35% reduction in video file size reduces the download time proportionally, particularly on mobile connections where bandwidth is limited and latency is high.
Browser support for WebM is broad among modern clients. Chrome, Firefox, and Edge all support WebM/VP9 natively without plugins. The main holdout is Safari on macOS and iOS, which added VP9 support only in Safari 14 (2020). For users on older Safari versions — a shrinking but non-negligible segment — you'll need a fallback strategy.
VP9 vs H.264: The Technical Difference
H.264, the codec inside most MP4 files, was finalized in 2003 and has been the dominant video codec for two decades. Its maturity means universal hardware acceleration: every smartphone, laptop, and TV manufactured in the last 10 years decodes H.264 in dedicated silicon, consuming minimal battery power. The tooling ecosystem is enormous — every video editor, every platform, every device can produce and consume H.264.
VP9, developed by Google and used in WebM containers, achieves superior compression by using more complex block prediction and entropy coding algorithms. At the same visual quality target, VP9 encodes fewer bits. The trade-off is encoding time — VP9 encodes significantly slower than H.264, which matters for video processing pipelines but is invisible to viewers.
On older mobile devices (pre-2016), VP9 decoding may lack hardware acceleration, falling back to software decoding. This can increase battery consumption and cause frame drops on low-end hardware. For audiences predominantly on modern devices, this is rarely a concern. For apps targeting older Android phones in developing markets, it's worth testing.
The Fallback Strategy: WebM + MP4
The correct implementation for production web use serves both formats and lets the browser choose. The HTML <video> tag with multiple <source> elements handles this natively:
<video autoplay muted loop playsinline>
<source src="hero.webm" type="video/webm" />
<source src="hero.mp4" type="video/mp4" />
</video>
The browser tries the first source it supports. Modern Chrome, Firefox, and Edge will use the WebM version. Safari and any browser that doesn't support WebM will fall back to MP4. This approach requires storing two files but delivers the optimal format to every visitor automatically.
The same principle applies to the <picture> element for images — the browser-negotiated format selection pattern is well-established and reliable. You don't need JavaScript or server-side user agent sniffing.
When to Stay With MP4
Several contexts make MP4 the right choice despite WebM's size advantage. Email attachments are the clearest case: Microsoft Outlook does not support WebM playback, and many email clients will show a broken video icon rather than attempting to play the file. Any video destined for email should be MP4.
Social media platforms — YouTube, Instagram, TikTok, LinkedIn — all accept and prefer MP4 H.264. While they transcode uploads into their own internal formats, submitting in MP4 H.264 is the format they've optimized their ingest pipelines for, and it produces the most predictable output quality.
Older mobile devices, particularly Android phones running versions prior to 5.0, have inconsistent VP9 support and may struggle with WebM playback. If your analytics show a meaningful portion of traffic on older Android devices, MP4 remains the safer universal choice. For public-facing tools, government sites, and applications serving diverse demographics, MP4 is the lowest-risk default.