AV1 vs H.264 vs H.265 for web video in 2026: the encoder showdown

I have been writing some version of "which codec should you ship" since 2019. It was easy in 2019 — the answer was H.264 and the only nuance was the profile. It got harder around 2022 when AV1 hardware decode started landing in consumer devices. It is hardest now, in 2026, because all three of H.264, H.265, and AV1 are viable, and the right answer genuinely depends on your audience, your tooling, and your willingness to ship multiple ladders.

This post is the version of that explanation I find myself emailing every two weeks. I am writing it down so I can link it.

Decoder support, as of May 2026

The single most important table in any codec post. Decoder support determines what you can ship; everything else is optimization.

¹ Chrome H.265 decode is hardware-only and requires a system codec. On Linux without the right install, it fails. ² AV1 HW decode requires a GPU shipped after late 2021 (RTX 30+, Intel Arc, Apple M3+, AMD RDNA 2+). Software decode is universal in modern browsers but expensive at 4K.

The shape of this table changed dramatically in the last two years. AV1 went from "Chrome and Firefox" to "everywhere, with hardware acceleration on anything bought after 2022." H.265 finally landed in Firefox in 2025, ending its long exile.

Bitrate vs quality, on real content

The interesting question is not "what is the maximum quality" — it is "at the bitrate you actually want to ship, how does each codec look." We run our internal benchmarks against three reference clips: a chart wipe (high contrast, hard edges), an editorial title sequence (subtle gradients, motion blur), and a product demo (UI elements + sweeping camera moves).

These are VMAF scores at 1080p60, encoded with the best widely-available encoder per codec (libx264 --preset slow, x265 --preset slow, SVT-AV1 --preset 6). Lower numbers are worse.

A few observations. AV1's advantage is largest at low bitrates — at 2 Mbps it is roughly 10 VMAF points ahead of H.264, which translates to "obviously cleaner" on side-by-side viewing. At 16 Mbps, all three look essentially identical; you are well past the point where the codec matters.

The practical implication: AV1 is the right call for bandwidth-constrained delivery (mobile, low-tier streaming). H.264 is still fine for desktop and broadband. H.265 is the awkward middle child — better than H.264, worse than AV1, and a licensing minefield.

Encoder availability and speed

A codec is only useful if you can produce it at the speed you can afford. Speed numbers from our CI runner (16-core Xeon, no GPU), encoding a 10-second 1080p60 clip at 8 Mbps:

The shape here is what you would expect: H.264 is fast, H.265 is slow, AV1 ranges from "slow" (SVT-AV1) to "absurd" (libaom). Hardware encoders close the gap, but only on the platforms that have them. CI runners almost never have GPU encoders.

If you are encoding once and serving many, AV1 with SVT-AV1 preset 6 is fine. If you are encoding per-request (personalized video, dynamic generation), AV1 is a non-starter without hardware. We covered the WebCodecs hardware path in detail in WebCodecs for deterministic video.

The licensing footnote nobody likes

H.264 is patent-encumbered, but the patents have a clean licensing path through MPEG-LA. In practice, every browser, every OS, every chip ships with it. You pay nothing as a developer.

H.265 is patent-encumbered through multiple incompatible pools (MPEG-LA, HEVC Advance, Velos Media). The legal exposure for shipping H.265 in a product is real and ambiguous. This is why H.265 was slow to land in browsers and why several large players actively avoid it.

AV1 is royalty-free. AOMedia governs it; the founding members (Google, Mozilla, Microsoft, Cisco, Netflix, Apple, Amazon, Meta) have committed to not pursuing patent claims. This is the single biggest reason AV1 has displaced H.265 as the heir apparent — not the compression gains, the licensing.

If you are picking a codec for a new product in 2026 and you have to pick one, the legal calculus favors AV1 over H.265 by a wide margin.

CDN compatibility

A practical thing that derailed several of our shipped projects: not every CDN can serve every codec equally well. Specifically, HLS and DASH support varies.

• H.264 in MP4 or fMP4 (HLS): works on every CDN, every player. The known-good path.
• H.265 in fMP4 (HLS): works on Apple platforms; works on most modern players; needs explicit configuration on some CDNs. Cloudflare Stream supports it; older Akamai configurations may not.
• AV1 in fMP4 (HLS): works in HLS since version 9. Player support is good in 2026 but you should test.
• AV1 in WebM (DASH): the cleanest AV1 delivery path. Universal browser support.

Our deployment recommendation: ship an HLS ladder with H.264 (for compatibility) + AV1 (for efficiency on capable clients), and let the player negotiate. Skip H.265 unless you have a specific reason.

A flowchart, because someone always asks

Here is the simplified decision tree I sketch on whiteboards.

Is this content delivered to many viewers, encoded once?
├─ Yes → Ship AV1 + H.264 fallback. Done.
└─ No (per-request render)
   ├─ Does the encoding machine have a GPU with AV1 HW encode?
   │   ├─ Yes → AV1.
   │   └─ No → H.264.
   └─ Is bandwidth the constraint?
       ├─ Yes → Suffer through software AV1.
       └─ No → H.264 and move on.

Notably absent: H.265 appears nowhere. In 2026, I cannot find a green-field reason to pick it. If you already have an H.265 pipeline shipping, keep it. If you are starting fresh, do not.

What HyperFrames ships, and why

For the curious: the HyperFrames CLI defaults to H.264 (avc1.640028, [email protected]) because it is universally playable. The --codec av1 flag emits AV1, and on machines with hardware encode (Apple Silicon M3+, modern Nvidia/AMD with the right drivers), it is roughly the same wall-clock as H.264. The CLI will warn you if you ask for AV1 on a machine without hardware encode and the resulting render would be more than 10× the duration of the input.

Our internal CI runs the full test suite against both codecs and verifies VMAF parity. The codec choice has not affected determinism since we moved to deterministic bitrate budgeting in late 2025 (the --target-bitrate and --qp flags).

What to watch in the next 18 months

A few things to keep an eye on, if you are operating at the codec layer.

• AV2 is in active development at AOM. Public encoders exist but are research-grade. Probably not shippable for another 24+ months.
• VVC (H.266) decoder support has not landed in any browser. It is technically excellent and politically dead.
• JPEG XS is becoming relevant for low-latency professional use (broadcast contribution, live editing). Not relevant for web playback.

The story for the web is, for once, settling down. We have a fast, free, efficient codec (AV1), and a fallback (H.264) that works everywhere. The interesting work in 2026 is not picking codecs — it is everything around them: deterministic encoding, frame-accurate timing (see our 2026 status report on timing), and the WebCodecs API maturing into something you can actually build on.

That is, refreshingly, a kind of boring future. Good.