Video devours bandwidth like no other format, and the codec decides whether a clip becomes a lean 50 MB file or a 200 MB lump. Three codecs dominate the field in 2026: H.264, H.265 and AV1. Which fits when, why "smaller" doesn't always mean "better", and what the difference between codec and container is.
First the terms: codec ≠ container
A common mix-up: the codec (H.264, AV1 …) compresses the actual video and audio data. The container (MP4, WebM, MKV) is just the shell that packages these data streams together with metadata.
A .webm file typically contains VP9 or AV1 video, an .mp4 mostly H.264 or H.265. So the extension says little about the actual compression. What matters is the codec inside.
The three codecs at a glance
H.264 / AVC: the universal standard
H.264 (also AVC) was finalized in 2003 and is to this day the most widely used video codec in the world. Every phone, every browser, every smart TV, every games console and every surveillance camera decodes it in hardware. Encoding is fast and resource-friendly.
Its drawback is efficiency: more modern codecs pack the same video significantly smaller at the same quality. Still, when in doubt H.264 is the safe choice, whether as the primary stream for a broad audience or as a fallback tier.
H.265 / HEVC: efficient, but license-burdened
H.265 (HEVC, 2013) compresses about 50 % better than H.264 at the same quality. The catch isn't the technology but the licensing: several patent pools at once (MPEG LA, HEVC Advance, Velos Media) plus independent patent holders make the total cost hard to calculate. This fragmentation is regarded as the main reason H.265 never caught on for the web.
Concretely for the web that means: Chrome and Firefox don't decode H.265 without hardware support. An H.265 video in a normal <video> tag fails silently there without a fallback. H.265 is therefore more at home in the Apple world and in live encoding, where mature hardware encoders (Apple VideoToolbox, NVENC, Quick Sync) play to its strengths.
AV1: royalty-free and the most efficient
AV1 was released in 2018 by the Alliance for Open Media (AOMedia), a consortium of Google, Netflix, Apple, Microsoft, Amazon, Meta, Nvidia, Intel and ARM. It is completely royalty-free and compresses another 30 % or so better than H.265, putting it clearly ahead of H.264.
The flip side: encoding is slow and compute-intensive. Hardware encoders so far exist only on newer GPUs (Intel Arc, Nvidia RTX 40 series, AMD RX 7000). Hardware decoders are more widespread, namely on devices from about 2022 onward (Apple M3+, Intel from the 11th generation, Nvidia RTX 30+, Snapdragon 8 Gen 2+). On devices from 2020 and older they're usually missing.
For the web, AV1 is paradoxically more consistent than H.265: current versions of all major browsers support it. YouTube already serves AV1 by default to supported devices, and so does Netflix.
Direct comparison
| Property | H.264 / AVC | H.265 / HEVC | AV1 |
|---|---|---|---|
| Year | 2003 | 2013 | 2018 |
| Efficiency vs. H.264 | Baseline | ~50 % smaller | ~50 % smaller (better than H.265) |
| License | one pool, capped | multiple pools, unclear | royalty-free |
| Encoding speed | fast | medium | slow |
| Hardware decode | everywhere | from ~2017 | from ~2022 |
| Browser web support | universal | patchy | broad & consistent |
What about H.266 / VVC?
VVC (H.266) is the designated HEVC successor and about 30–50 % more efficient than H.265, comparable to AV1. But as of 2026 there's practically no hardware support, and the license structure recalls that of HEVC. Adoption is likely to be correspondingly slow. For practical purposes, VVC is not yet a topic today.
Decision guide
- Maximum compatibility, every device → H.264 (MP4)
- Web delivery with small files → AV1 (WebM/MP4), H.264 as fallback
- Apple ecosystem, live streaming → H.265, where a hardware encoder is available
- Royalty-freedom matters → AV1 or VP9
- Fast live encoding without a strong GPU → H.264
The robust strategy for the web remains a fallback chain: AV1 for modern devices, H.264 as the universal fallback. This resembles the <picture> logic for images, only with several <source> entries in the <video> element.
All about converting at wandlio
How conversion without uploads even works, and why some formats run locally in the browser and others server-side, we explained here: How does in-browser file conversion work?
Already usable locally in the browser today:
Your file is always deleted, with no account and no permanent upload.