Best Video Format for a Website in 2026: MP4, WebM, or AV1?

Judged on browser reach, the best video format for a website is MP4 with H.264 when one file must reach the widest browser audience. Add WebM/VP9 as a second source when its measured output is smaller for your content. Test AV1 behind a fallback, never as an AV1-only file. For longer videos, adaptive delivery can produce a larger speed improvement than changing the file format.

The short answer, by use case

Start with the job the video has to do. A muted loop in a hero section has a different delivery problem from a 45-minute course lesson. The table gives you a starting decision before the codec details.

For a background video, keep the visual loop short, muted, and optional. The background-video guide covers the HTML and CSS behavior. The question here is narrower: which file, and delivered how.

MP4 vs WebM for website delivery

MP4 and WebM are containers; H.264 and VP9 are the codecs inside those containers. If you want the full container comparison, read the full breakdown of video container formats. For a website, the useful question is narrower: which encoded source can this browser play, and how many bytes will this visitor receive?

MP4/H.264 is the reliable single-source choice

MP4/H.264 remains the right default when you have one file, one URL, or a site that must work for an unknown audience. It has the widest reach of any option in this comparison, and reach is the whole job of a single source. A file nobody can decode saves zero bytes.

WebM/VP9 is a useful second source, not an automatic upgrade

WebM/VP9 is practical as a second source in 2026. Newer Safari and iOS Safari versions support it, while older Apple browsers keep the fallback source in play.

VP9 quality is comparable to HEVC at similar bit rates, and VP9 is open and free of royalties and other licensing requirements (MDN, 2026). But “WebM is 20–35% smaller” is not a universal fact. The codec, source material, target quality, encoder, and viewer distribution all change the result. Measure the delivered output for your actual video before promising a percentage.

WebM vs MP4 for a website: the operational decision

Use both when the second encode has a clear benefit and your player can select it cleanly. Keep MP4/H.264 in the list as the fallback — a slightly smaller source is useless if the browser cannot decode it. For a five-second muted loop, the extra encode and source tag rarely pay for themselves. For a video downloaded thousands of times a month, they do.

AV1 vs H.264: what the compression numbers actually mean

AV1 can be substantially more efficient than H.264, but a benchmark is not the same thing as a visitor’s bandwidth bill. The most useful comparison has two layers: matched-quality lab results, then the savings that survive a real delivery system.

Lab efficiency: AV1 leads, but content changes the result

A June 25, 2026 comparison from Fora Soft measured BD-rate at matched VMAF across six content categories using x264, x265 4.2, and SVT-AV1 4.0.0. Its mean result was about 44% less bitrate for HEVC than H.264 and about 55% less for AV1 than H.264; AV1 used about 20% less bitrate than HEVC (Fora Soft, 2026).

The content spread matters more than the headline. In that test, AV1’s savings versus H.264 ranged from about 48% for sports and 48% for user-generated video to nearly 64% for animation. A single “AV1 is 55% smaller” claim hides the decision you actually need to make: what kind of motion, texture, grain, text, and camera noise does your video contain?

Delivered bandwidth: lab BD-rate is not the result your visitors see

BD-rate compares encodes at matched quality. It does not tell you how much bandwidth your site will save after source selection, device support, bitrate ladders, caching, viewing behavior, and the mix of browsers are included.

Jan Ozer’s own encoding test, built using Netflix’s convex-hull technique, found that libvpx-VP9 produced the same quality as x264 at a 21.06% lower average bitrate. When he modeled three viewer-distribution scenarios, the delivered savings were 11.4%, 15.2%, and 6.5%—not 21.06%. His conclusion is the important part: “BD-Rate numbers can’t be used to estimate real-world savings” (Streaming Learning Center, 2021).

None of this makes AV1 or VP9 unhelpful — it changes how you evaluate them. Compare total bytes delivered and playback outcomes from your own audience, rather than multiplying a lab percentage by your monthly transfer volume.

AV1 in production: a long-form result, not a hero-video promise

Netflix reported in December 2025, from a snapshot dated November 13 of that year, that AV1 represented approximately 30% of its streaming and that AV1 sessions used one-third less bandwidth than AVC and HEVC, with 45% fewer buffering interruptions (Netflix Technology Blog, 2025).

Read the fine print: those are session-level results from long-form entertainment delivered through a full adaptive bitrate ladder and client stack. Netflix's numbers prove AV1 pays off at production scale. They do not promise that switching a 20-second homepage video to AV1 will cut rebuffers by 45%. For a short single-file video, browser reach and startup bytes are the more direct questions.

H.265 vs H.264: efficiency you cannot play is worth zero

HEVC can reduce bitrate substantially in a matched-quality test: the Fora Soft result was about 44% less than H.264. The reach trade-off is severe, and “partial support” does not mean the playback path you want is available on every device.

HEVC also carries a more complicated licensing position than VP9 or AV1. That is workable when you control the devices — an Apple-only app, a kiosk, a set-top box. On an open website, it is the wrong default unless you have measured both your audience and your fallback path.

Browser reach, in numbers

Browser percentages are global-usage-weighted, not a promise about your visitors. They move as browsers update, so treat this table as a dated planning snapshot from August 7, 2026.

The AV1/Safari hardware-decoder trap

AV1 support in Safari is not a blanket “Safari 17+” yes. MDN says Safari support is limited to devices with a hardware decoder, including M3 MacBooks and later, iPhone 15 Pro, and iPhone 16 and later (MDN, 2026).

An AV1-only page can fail silently for visitors on earlier Apple hardware. AV1 is royalty-free and a sensible source to test when you control encoding and fallbacks; it is not a reason to remove MP4 from a public website.

How to serve more than one format

The simplest browser fallback is still a list of sources. The browser picks the first one it can play, and explicit type values let it decide without downloading anything first.

<video controls playsinline width="1280" height="720">
  <source src="video.av1.mp4" type="video/mp4; codecs=av01.0.08M.08">
  <source src="video.webm" type="video/webm; codecs=vp9">
  <source src="video.mp4" type="video/mp4; codecs=avc1.4d401f">
  Your browser does not support HTML video.
</video>

Put the source you want eligible browsers to try at the top of the list, and keep the H.264 source at the bottom. If you only have two files, WebM/VP9 followed by MP4/H.264 is a reasonable order. Add AV1 only when you have measured its encoding cost, playback reach, and delivered-byte benefit for your audience.

The HTTP Archive found that only one in ten mobile video elements had multiple sources in its 2024 media data; 48.9% had one source and 42.5% had no source children (HTTP Archive Web Almanac, 2024). Real sites are not following the multi-format advice tutorials hand out. Whether that is a mistake depends on the video — but it is a useful reality check before you commit to maintaining three encodes.

Keep preload and poster behavior aligned with the page’s purpose; the web-video optimization guide covers those controls in detail. Format selection is only one part of the request path.

When the format stops mattering

Short videos make up much of the web video sample in the HTTP Archive’s 2024 media chapter. For a video under roughly 30 seconds—such as a short hero loop or product teaser—a well-encoded MP4 with a sensible display size can be the complete answer. You may save bytes with a second source, but the format decision has a ceiling.

Above 30 seconds, the delivery model becomes the constraint

Longer videos expose a different failure mode: the visitor’s connection changes while the file is playing. With progressive download, a slower network drains the buffer and leaves the viewer staring at a spinner; Mux describes this as having “no fallback.” Its adaptive bitrate guide targets startup under two seconds and calls 4–6 second segments a reasonable default for most VOD; the 8–12 second figure it quotes for standard HLS is a live-stream latency target, not something a website video pays (Mux).

Adaptive bitrate streaming takes over from the MP4-versus-WebM argument here. The player can select different quality levels as the connection changes instead of asking one file to fit every viewer. The 2024 HTTP Archive media data found that 9% of video files were .ts segments and 4% were .m4s segments. The Almanac groups those with the 14% that carry no extension at all as the trio “delivered when a <video> element employs adaptive bitrate streaming using either HLS or MPEG-DASH” — 27% of video files between them (HTTP Archive Web Almanac, 2024). Either way it is a practical signal of adaptive delivery rather than a single progressive file.

If you need the protocol distinction, read how HLS streaming prevents buffering or DASH vs HLS, compared. The decision here is simpler: one short file favors format choice; a longer video on variable connections favors an adaptive ladder and a delivery network.

Page speed is also about what arrives before playback

Video can affect Core Web Vitals, but the codec is not automatically the first byte on the clock. Google defines a good Largest Contentful Paint as 2.5 seconds or less and says a <video> can use its poster image load time or first-frame presentation time for LCP, whichever comes earlier (web.dev LCP guidance, 2026).

So the initial request path, poster, player JavaScript, and first playable bytes matter as much as the compression ratio. The HTTP Archive reported that 2025 median video bytes rose 28% year over year from 246 KB to 315 KB, while the median total page weight was 2,164 KB on mobile and 2,412 KB on desktop (HTTP Archive Web Almanac, 2025). Do not spend a day tuning AV1 while a third-party embed or an oversized player still blocks the page.

What the numbers mean for your site

Use this sequence to make the choice without over-engineering it:

1. Start with reach. If the page needs one file, choose MP4/H.264. Its browser reach is more valuable than a codec that saves bytes but requires a fallback.
2. Test a second source. Compare WebM/VP9 or AV1 against H.264 using the same source video and a quality target. Record actual delivered bytes, startup time, and playback failures.
3. Check the audience, not a global average. Your analytics may show a different Apple, Android, desktop, or embedded-browser mix from Can I Use’s global weighting.
4. Switch the delivery model for long playback. Once the video is long enough for network conditions to change, adaptive bitrate delivery is more useful than adding a fourth file format.

One practical caveat: the format is not the same as the complete page experience. Our own measurement, published on the SmartVideo features page, puts a SmartVideo embed at about 707 KB against 1,513 KB for a YouTube embed, with 17 versus 25 requests and 2 versus 7 third-party domains. That is a player and embed-path comparison, not a claim that AV1 is a certain percentage faster than H.264. The distinction matters when you are diagnosing a slow page.

For a broader look at why video delivery affects conversions, read why video load speed costs you conversions. For file-size mechanics and encoding workflows, use the guide to reducing video file size, which covers the encoding side in depth.

FAQ

For most sites, the decision is straightforward: ship MP4/H.264 when universal playback is the priority, add WebM or AV1 when measured savings justify the extra source, and move to adaptive delivery when the video is long enough that one file cannot fit every connection. If you would rather upload a master and let the player handle the ladder, try SmartVideo free.