MP4 vs WebM for the web - when to use each format

Published April 20, 2026

---

MP4 and WebM are the two container formats that matter on the modern web. MP4 almost always carries H.264 (AVC) video with AAC audio; WebM almost always carries VP9 or AV1 video with Opus audio. The right choice depends on where your video plays, how much bandwidth it consumes, and how long you’re willing to wait for the encode. This guide covers the codec economics, the browser-support reality in 2026, and the three real production decisions that determine which container ships.

Container vs codec - what each file actually holds

A container wraps video, audio, and metadata into a single file that a player can read. MP4 (ISO base media) and WebM (a restricted Matroska profile) are both containers. The codec is how the video pixels and audio samples are compressed. An MP4 can, in theory, carry almost any codec, but in practice the web ecosystem treats MP4 as an H.264 file. WebM is purpose-built for royalty-free codecs - VP8 (rare in 2026), VP9 (mainstream), and AV1 (newest, highest compression).

When the decision is framed as “MP4 or WebM,” the real decision is H.264 vs VP9 vs AV1 - which codec to encode. The container follows the codec. H.264 ships in MP4; VP9 and AV1 ship in WebM on the web.

Codec size comparison for the same visual quality

Browser support reality in 2026

MP4/H.264 plays in 100% of shipping browsers - Chrome, Firefox, Safari, Edge, every mobile WebView. Has for a decade. If a video playing matters more than bytes saved, ship H.264.

WebM/VP9 plays in Chrome, Firefox, Edge, Opera, and Safari (since Safari 14, macOS Big Sur, 2020). Mobile Safari on iOS 14+ supports VP9. A very small residual audience on legacy iPhones below iOS 14 cannot decode VP9.

WebM/AV1 plays in Chrome 70+, Firefox 67+, and Edge 75+. Safari added AV1 support in 17.4 (2024). Hardware AV1 decode requires relatively new silicon - Intel 11th gen (Tiger Lake) or later, Apple M3 or later, AMD 6000 series or later. Pre-2022 devices fall back to software decode, which drains battery and can drop frames on 4K content.

The <source> fallback pattern

The canonical HTML5 video pattern serves the best codec the browser can decode and falls back down the list:

<video controls preload="metadata" poster="cover.jpg">
  <source src="clip.av1.webm" type="video/webm; codecs=av01.0.05M.08">
  <source src="clip.vp9.webm" type="video/webm; codecs=vp9,opus">
  <source src="clip.h264.mp4" type="video/mp4; codecs=avc1.4D401F,mp4a.40.2">
  <p>Your browser does not support HTML5 video.</p>
</video>

The browser walks the <source> list top-down, picks the first type it recognises, and ignores the rest. Serving AV1 first captures the ~60% of 2026 devices that have hardware AV1 decode; VP9 catches most of the rest; H.264 guarantees 100% fallback.

The three real production decisions

Decision 1 - Short social clip for broadest reach. → MP4 (H.264) only. Encode once. Every browser, every social platform, every email client plays it. Bandwidth savings of VP9/AV1 do not justify the encode time and the edge-case devices you’d miss.

Decision 2 - Background hero video on a marketing site at 1080p, 15-second loop. → MP4 (H.264) + WebM (VP9). The VP9 file ships at ~60% of the H.264 size, helping Core Web Vitals on users with slow connections. The H.264 file is the fallback for anyone whose browser skips WebM. Encode time is small (one-time, 15-second clip).

Decision 3 - Long-form streaming library (VOD service, course platform, 30+ minute videos). → AV1 (WebM) + VP9 (WebM) + H.264 (MP4). The AV1 files save substantial CDN egress at scale. The VP9 files cover every modern browser. The H.264 files are the universal fallback. Encode on GPU hardware or a batch pipeline; AV1’s 10× encode time matters when the library has thousands of videos.

Encoding recipes

H.264 (MP4) - the safe universal. A single FFmpeg one-liner hits the sweet spot for web delivery: ffmpeg -i in.mov -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart out.mp4. The +faststart flag puts the moov atom at the start of the file so a browser can begin playback before the full file downloads.

VP9 (WebM) - best compression/compatibility balance. Use two-pass encoding for consistent quality at a target bitrate. -c:v libvpx-vp9 -b:v 0 -crf 31 -row-mt 1 -c:a libopus -b:a 96k. The -row-mt 1 flag enables row-based multi-threading that cuts encode time roughly in half on modern CPUs.

AV1 (WebM) - maximum compression. SVT-AV1 is the encoder the industry settled on: -c:v libsvtav1 -crf 35 -preset 6 -c:a libopus -b:a 96k. Preset 6 is the default balance between speed and compression; lower presets (4, 5) favour quality at the cost of much longer encodes.

When to avoid WebM entirely

If your audience is primarily iOS < 14, older Android WebView, or legacy enterprise browsers, WebM offers no benefit - those devices will fall through to the H.264 source anyway, and the WebM encode is wasted effort. If the video is user-generated content that viewers often save, re-share, or edit, H.264 MP4 is the format they expect their tools to accept.

Email clients almost never render <video> natively. If the video is in an email newsletter, export a short animated GIF or an MP4 link to a landing page - neither WebM nor an inline HTML5 video tag help.

Converting between formats

Our video converter handles MP4 ↔ WebM in the browser with FFmpeg.wasm - no upload, no install. For long-form batch conversion, install FFmpeg locally and use the recipes above; the in-browser converter is bounded by your available RAM (typically 2–4 GB per tab), which works for individual clips but not a 50-video catalog. See our FFmpeg online vs local comparison guide for when each wins.

Related tools

• Video Converter - MP4, WebM, MOV conversion in-browser.
• FFmpeg Online - command-line FFmpeg in the browser.
• Video Maker - stitch images into a video clip.
• Compress Image - reduce cover-image file size.

← Back to Video Tools