Every video you have ever streamed was a lie told very carefully.

An uncompressed 1080p60 video signal runs at roughly 3 Gbps. Your viewer's connection is maybe 25 Mbps on a good day. Something has to bridge a gap of more than a hundred times — and that something is the codec, throwing away the overwhelming majority of the original data while betting that the human eye will not notice which parts went missing.

Which bet it makes, and how expensive that bet is to compute, is the whole subject of this article.

What is a video codec?

A codec (coder-decoder) is the algorithm that compresses video for storage and transport, then reconstructs it for playback. It exploits two kinds of redundancy: spatial — neighbouring pixels in a frame tend to look alike — and temporal — consecutive frames tend to look alike. Instead of describing every frame in full, it describes the differences.

Two distinctions cause most of the confusion in this area:

• A codec is not a container. MP4, MKV and WebM are containers: boxes holding video, audio, subtitles and metadata. H.264 is what is inside the box. "MP4 vs H.264" is not a meaningful comparison.
• A codec is not a protocol. HLS and MPEG-DASH decide how segments get requested and delivered; the codec decides how those segments were compressed in the first place. Our guide to streaming protocols covers the delivery half of the stack.

Every codec decision is a negotiation between four costs, and you cannot minimise all of them at once:

1. Bitrate — what you pay in bandwidth and CDN egress.
2. Quality — what the viewer sees.
3. Compute — what you pay to encode, and what the viewer's device pays to decode.
4. Compatibility — how many devices can play it at all.

Improve compression and you spend more compute. Adopt a newer codec and you lose compatibility. That triangle is the entire story.

The four codecs that actually matter

H.264 / AVC — the one that always works

Standardised in 2003 and still, two decades later, the default. Its compression is comfortably beaten by everything newer, and it does not care.

H.264 wins on one axis so decisively that it compensates for losing on all the others: it plays everywhere. Every browser, every phone, every smart TV, every set-top box built this century, with hardware decoding baked into the silicon. There is no device in meaningful circulation that cannot play H.264.

• Compression: the baseline everything else is measured against.
• Encoding speed: fast, mature, cheap. Every encoder implementation has had twenty years of tuning.
• Licensing: patent pool royalties apply, though the terms are well understood and streaming is largely covered in practice.
• Ceiling: effectively 1080p. It handles 4K badly — the bitrates get absurd.

Use it as your compatibility floor. Almost every sensible ladder still includes H.264 renditions for exactly this reason.

HEVC / H.265 — better compression, worse politics

HEVC delivers roughly 25–50% bitrate savings over H.264 at equivalent quality, with the larger gains at higher resolutions. It was designed for the 4K and HDR era, and technically it delivers.

Then licensing happened. Instead of one patent pool there were several, with overlapping claims and uncoordinated terms. The resulting uncertainty scared the web away: HEVC still has no meaningful support in Chrome or Firefox on desktop.

What it does have is Apple. Safari, iOS and tvOS support HEVC well, with hardware decoding across the Apple range, and broadcast and smart-TV ecosystems adopted it thoroughly.

• Use it if: your audience is Apple-heavy, you ship native apps, you are targeting connected TVs, or you serve 4K/HDR.
• Skip it if: you are browser-first on the open web.

VP9 — Google's answer, quietly everywhere

Royalty-free, open, and developed by Google to avoid the licensing mess entirely. Compression sits in broadly the same territory as HEVC — call it 20–50% better than H.264 depending on content and encoder settings.

Its real advantage is a support profile that is almost the mirror image of HEVC's: strong in Chrome, Firefox and Edge, present on Android, absent on older Apple hardware. YouTube has served enormous volumes of VP9 for years, which is why it works reliably in practice rather than just on paper.

• Use it if: you are browser-first and want savings today without royalties.
• Watch out for: encoding is meaningfully slower than H.264, and Apple support is patchier than you would like.

AV1 — the endgame, once the hardware catches up

AV1 came out of the Alliance for Open Media — Google, Amazon, Netflix, Meta, Microsoft, Mozilla, Apple and others in the same room, which tells you how badly the industry wanted out of the HEVC situation. It is royalty-free by design.

Compression is the best of the four: roughly 30% better than VP9 and HEVC, and 50% or more better than H.264. On low-motion and animated content the gains can be larger still.

The catch has always been compute. Early AV1 encoders were slow to the point of impracticality — orders of magnitude slower than H.264. That has improved enormously (SVT-AV1 in particular), but AV1 encoding is still the most expensive option by a wide margin.

Decoding is the other half. AV1 hardware decode now ships in recent GPUs, flagship mobile chipsets and newer smart TVs, but "recent" is doing real work in that sentence. Software decode on an older phone drains battery and drops frames.

• Use it if: you have high-volume, long-tail content where bandwidth savings compound, and a modern audience.
• Skip it if: your catalogue turns over quickly, or your audience skews toward older devices.

The comparison in one place

Treat the percentage ranges as directional. Real savings depend heavily on content — a static talking-head lecture and a handheld sports clip compress nothing alike — and on how carefully the encoder is tuned. Anyone quoting a single precise figure is selling something.

How to actually choose

Forget "which codec is best" — the question is which combination fits your audience, catalogue and budget.

If you are starting out or your audience is unknown: ship H.264 only. One codec, one ladder, no complexity, plays everywhere. The bandwidth you overspend is cheaper than the engineering time and the support tickets from a device you did not test.

If you are browser-first with real volume: H.264 as the floor, VP9 on top. Chrome and Firefox users get the savings, everyone else falls back gracefully. This is the pragmatic middle and it has been for years.

If you ship native mobile and TV apps: H.264 plus HEVC. Apple devices and smart TVs take the HEVC ladder with hardware decode; the rest fall back.

If you are at a scale where CDN egress is a line item that hurts: add AV1 for your most-watched content. This is the crucial nuance — you do not need to encode your whole catalogue in AV1. Viewing is power-law distributed. Encode the top few percent of titles that drive most of the watch time, leave the long tail on H.264, and you capture most of the savings for a fraction of the encoding bill.

If you serve 4K or HDR: H.264 is not a serious option. Pick HEVC or AV1 based on where your viewers are.

The economics, briefly

The trade is simple: encoding is a one-off cost per asset, delivery is a recurring cost per view.

That single sentence decides most codec strategies. A title watched a hundred times will never repay expensive encoding. A title watched a hundred thousand times repays it many times over. So the honest rule is: let watch time decide the codec, not the upload date.

Which is why a per-title, popularity-aware approach beats a blanket policy in both directions — blanket H.264 overspends on delivery for your hits, blanket AV1 overspends on compute for your long tail.

Do the arithmetic before committing. Take your monthly egress, multiply by a realistic saving for the share of your audience that can actually decode the new codec — not your whole audience — and compare it against the encoding bill. It is frequently a smaller win than the marketing suggests, and occasionally a much bigger one.

Things that quietly matter more than the codec

Teams agonise over codec choice while leaving larger gains on the table.

• Your bitrate ladder. A badly designed ABR ladder wastes more bandwidth than any codec choice recovers. Rungs too close together, a top rung nobody can reach, no rung for poor connections — these are common and expensive.
• Per-title encoding. Using the same bitrate for a screencast and a football match is leaving 20–30% on the floor. Analyse complexity per asset and adjust.
• Your CDN. Cache hit ratio and origin placement affect both cost and startup time, immediately, regardless of codec.
• Resolution and frame rate discipline. Not everything needs 4K60. Our post on choosing the right frame rate covers where the perceptual returns stop.
• Audio. Frequently forgotten, frequently encoded at twice the necessary bitrate across every rendition of the ladder.

Codecs are the glamorous part of the stack. The ladder is where the money is.

What comes next

VVC / H.266 offers another significant step beyond HEVC, and appears to be repeating HEVC's licensing history, which historically has been fatal for web adoption regardless of technical merit.

AV2 is in development at the Alliance for Open Media, aiming to extend AV1's lead while staying royalty-free.

Neither should influence a decision you make this year. Codec transitions run on hardware replacement cycles, and those take the better part of a decade. H.264 was standardised in 2003 and remains the safest thing you can ship in 2026 — that is the timescale this industry actually moves on.

Frequently asked questions

Do I have to choose just one? No, and you probably should not. Modern adaptive streaming lets you publish multiple codecs in one manifest and let each player pick what it can decode. The cost is storage and encoding time, not compatibility.

Is AV1 ready for production? For encoding, yes — the tooling is mature enough. The open question is your audience's hardware. Check your analytics for device age before committing, and always keep a fallback ladder.

Will HEVC ever come to Chrome? Support has appeared in limited, hardware-dependent forms, but treat it as unreliable for the open web. If your delivery target is the browser, VP9 and AV1 are the sane choices.

Does a better codec improve quality, or just reduce bitrate? Either — it is the same lever from two ends. You can hold quality and cut bitrate, or hold bitrate and raise quality. Most operators take the saving.

How much can I actually save moving to AV1? Less than the headline number, because only the portion of your audience with AV1 decode gets the smaller files. Multiply the compression gain by your addressable device share before building a business case on it.

The correct codec strategy is rarely the most advanced one. It is the cheapest combination that reaches every viewer you care about — usually a compatibility floor plus one modern codec for the audience that can use it, with the balance revisited as hardware turns over.

If you would rather not run that pipeline yourself, that is roughly the point of a managed platform. Teyuto handles transcoding, packaging and adaptive delivery so you publish once and every device gets a stream it can actually play. Start free and see what your catalogue looks like when the encoding stops being your problem.

← All articles