For web playback in 2026, ship MP4 (H.264 video, AAC audio) as the universal baseline and add WebM (VP9 or AV1) as a smaller-file upgrade for browsers that decode it well. In the mp4 vs webm decision, the codec inside the container matters more than the container itself. VP9 typically cuts file size by 30 to 50 percent against H.264 at equal visual quality, and AV1 cuts roughly another 20 to 30 percent. H.264 in MP4 remains the only combination that every major browser and device decodes in hardware.
As of 2026, H.264 in an MP4 container plays in Chrome, Edge, Firefox and Safari on every platform, while WebM playback in Safari still depends on OS version and hardware decode support. MP4 is therefore the mandatory fallback and WebM the optional bandwidth saver, typically 30 to 50 percent smaller. The browser picks between them through ordered source elements, so no server-side negotiation is needed.
Verdict, evaluated October 2026: ship H.264 MP4 alone for low-traffic marketing pages and short clips. Serve WebM plus MP4 when monthly video egress is large relative to library size, because the egress savings then outweigh the cost of a second rendition. Move to HLS or DASH once clips run longer than a few minutes or viewers sit on variable mobile networks.
MP4 is the ISO Base Media File Format container (ISO/IEC 14496-12 and 14496-14). On the web it carries H.264/AVC, H.265/HEVC or AV1 video, with AAC or Opus audio. WebM is a restricted profile of Matroska. It allows only VP8, VP9 or AV1 video, with Vorbis or Opus audio.
The overlap is AV1 and Opus, which both containers can hold. "MP4 vs WebM" is really a question of which codec families a target browser can decode efficiently, and which muxing details affect progressive playback. A file named .webm with AV1 inside and a file named .mp4 with AV1 inside compress identically. They differ only in container overhead, which is well under 1 percent for typical clips, and in tooling support.
H.264 MP4 plays everywhere, and that has been true for over a decade. WebM with VP9 plays in Chrome, Edge and Firefox on desktop and Android. Safari added WebM VP9 on macOS in version 14.1, and its iOS support arrived later and varies by device. AV1 decodes in Chromium browsers and Firefox, and in Safari only on Apple hardware with an AV1 decoder (A17 Pro, M3 and newer).
| Criterion | MP4 (H.264 / AAC) | WebM (VP9 / Opus) | WebM or MP4 (AV1 / Opus) |
|---|---|---|---|
| Browser coverage | All major browsers and devices | Chromium, Firefox; Safari version-dependent | Chromium, Firefox; Safari only with hardware AV1 |
| Size at equal quality | Baseline (100) | About 50 to 70 | About 35 to 55 |
| Encode time vs x264 | 1x | Roughly 3x to 10x (libvpx) | Roughly 2x to 20x (SVT-AV1 presets) |
| Hardware decode | Universal | Most devices since about 2017 | Devices from about 2020 onward |
| Alpha transparency | No (Safari uses HEVC with alpha instead) | Yes in Chromium and Firefox | Limited browser support |
H.264 MP4 wins on reach and encode cost, and WebM wins on bytes, so the fallback is never optional.
Size ratios are typical ranges from public codec comparisons, not guarantees. Animated content, screen recordings and film grain shift them in both directions, so measure on your own clips.
At matched perceptual quality (equal VMAF), a 1080p clip that needs about 5 Mb/s in H.264 typically lands near 2.5 to 3.5 Mb/s in VP9 and 1.8 to 2.8 Mb/s in AV1. These are labeled ranges. Gains shrink at low resolutions and very high bitrates, and they grow on detailed, slow-moving footage.
Two caveats matter more than the headline ratio. First, x264 at its slow preset is a mature encoder. A rushed VP9 single-pass encode can lose to it outright, so compare two-pass VP9 or constrained-quality modes against your actual H.264 settings. Second, decode cost moves to the client. VP9 or AV1 without hardware decode raises CPU load and drains batteries on older phones. That is why Safari and some Android builds deprioritize software VP9 even where it technically plays.
Progressive playback. An MP4 whose moov atom sits at the end of the file cannot start until the browser fetches the tail with an extra range request. Remux every web MP4 with the moov atom at the front (the faststart movflag in ffmpeg). WebM has the equivalent problem with its Cues element, which most muxers write at the end. Seeking then costs an extra range request until you remux with cues at the front or run the file through a tool such as mkclean.
Tooling and pipelines. Every encoder, editor, CMS and analytics player handles H.264 MP4. WebM support is good in browsers and ffmpeg but thinner in enterprise video platforms, ad stacks and some social embeds.
Encode budget. A second rendition is a second encode job. VP9 with libvpx at good quality runs several times slower than x264, so a large back catalog can mean days of compute before the egress savings appear.
Transparency. WebM VP9 with an alpha channel is the practical way to ship transparent video overlays in Chromium and Firefox. Safari needs a separate HEVC-with-alpha MP4, which makes dual-format delivery mandatory for that use case.
Dual-format delivery pays when the egress saved each month exceeds the extra storage plus amortized encoding. Monthly egress saved equals egress times the share of plays that pick WebM times the size reduction. Extra storage equals library size times the WebM-to-MP4 size ratio.
Here is a worked example with labeled assumptions. Take 100 TB a month of H.264 MP4 egress and a 10 TB library of web renditions. Assume 70 percent of plays come from browsers that select VP9 WebM, and that VP9 files are 35 percent smaller.
Price per TB decides the outcome. With storage at about $20 per TB-month and delivery at $5 per TB, dual format breaks even only when monthly egress exceeds roughly 10.6 times the library size (0.65 times 20, divided by 0.245 times 5). At Amazon CloudFront pay-as-you-go pricing, about $6,965 for 100 TB (published price lists, checked August 2026, effective $69.65 per TB), the break-even falls to roughly 0.8 times library size. The 24.5 TB saved would be worth on the order of $1,700 a month, which is our estimate.
This blog's rule of thumb follows from that math. On expensive egress, a second WebM rendition almost always pays. On cheap egress, it pays only for hot libraries where a small catalog drives heavy traffic. Encoding compute is excluded above because it is a one-time cost. Add it if you re-encode often.
Let the browser choose. Inside the video element, list source children in order of preference: AV1 first, then VP9 WebM, with H.264 MP4 last as the fallback. Give each source a type attribute that includes the codecs parameter, for example video/webm with codecs vp09.00.40.08 and video/mp4 with codecs avc1.640028. Without the codecs string, a browser may pick a WebM file it can only decode in software.
On the delivery side, follow these rules:
For libraries that double in object count, keeping both renditions resident at the edge matters more than raw per-TB rates. The BlazingCDN Video CDN for MP4 and WebM libraries replicates the library inside the CDN with permanent cache at $0.02 per GB per month after the first 500 GB, which is included, as of October 2026. Current rates are on the BlazingCDN pricing page.
No single format is best for every page. The right pick depends on clip length, traffic volume and audience devices. The matrix below maps common web workloads to the format strategy that fits as of 2026.
| Workload | Best fit | Why |
|---|---|---|
| Low-traffic marketing clips | H.264 MP4 only | Egress saved is smaller than the pipeline complexity |
| Autoplay hero loops, short and muted | VP9 or AV1 WebM plus H.264 MP4 | Loaded on every visit, so bytes compound quickly |
| Transparent overlays | VP9 alpha WebM plus HEVC alpha MP4 | No single file covers both Chromium and Safari |
| High-traffic product or tutorial video | AV1 plus VP9 WebM plus H.264 MP4 | Egress-to-library ratio clears break-even |
| Long-form VOD, mobile-heavy audience | HLS or DASH with fMP4 segments | Adaptive bitrate beats any single progressive file |
Progressive WebM plus MP4 is the right choice for short, frequently loaded clips, while long-form video belongs in adaptive streaming.
Usually yes, if WebM carries VP9 or AV1 and the MP4 carries H.264. VP9 typically saves 30 to 50 percent at equal perceptual quality, and AV1 saves more. If both containers hold AV1, sizes are essentially identical, because the codec drives compression and container overhead stays well under 1 percent for typical web clips.
Partly. Safari on macOS has played WebM VP9 since version 14.1, and iOS support arrived later and depends on device and OS version. AV1 plays only on Apple hardware with an AV1 decoder. Always list an H.264 MP4 fallback after any WebM source so older iPhones and iPads still play the video reliably.
Use both, with WebM first and H.264 MP4 as the fallback. Background loops load on every page view, so a 30 to 50 percent smaller WebM file cuts real egress and improves Largest Contentful Paint on Chromium browsers. Keep the clip muted, short and remuxed for fast start, because autoplay policies require muted playback.
It can on long-tail catalogs, because each asset becomes two cached objects that each receive fewer requests. Separate URLs per format keep cache keys clean, so the effect is limited to request dilution. Pre-warming popular renditions and using an origin shield keeps MP4 and WebM hit ratios close to single-format levels.
MP4 wins for adaptive streaming. HLS uses fragmented MP4 or MPEG-TS segments, and fragmented MP4 (CMAF) is the common format shared by HLS and DASH. DASH can carry WebM segments, but player and device support is thinner, so most production pipelines package VP9 or AV1 in fragmented MP4 instead of WebM.
This week, pull last month's video egress in TB and your web-rendition library size. Then split plays by browser family from your analytics. Encode your ten most-played clips to VP9 at matched VMAF, measure the real size reduction, and plug the three numbers into the break-even formula above. If egress exceeds the break-even multiple of library size, add WebM sources for those clips first. Then check the hit ratio and 206 response rates per format at the edge for two weeks before converting the rest of the catalog.
If the math favors dual-format delivery at volume, BlazingCDN's VOD delivery for MP4 and WebM catalogs runs a 14-day testing period on real production traffic at $5 per TB with the monthly minimum waived.