H.264, H.265 and AV1: which video codec to actually export with

A codec is the set of rules for turning pictures into bits and back. Newer ones are cleverer, which means they need fewer bits for the same picture — and cleverer costs time, both to encode and to decode. Every codec choice is that one trade, and the right answer depends entirely on who has to play the file.

H.264 (AVC)

Standardised in 2003 and still the default answer to most questions. Its compression is beaten comfortably by everything below it, and it does not matter much, because H.264 plays on literally everything — every phone made this century, every browser, every TV, every editing program, every messaging app.

It also encodes fast, and it has hardware encoders in essentially every chip, so a phone can produce it in real time without the battery noticing.

Pick H.264 when the file is going to someone else and you do not control what they will open it with. The extra megabytes are cheaper than the message that says "this won't play".

H.265 (HEVC)

The direct successor, and roughly 40–50% smaller than H.264 at the same visual quality. That is a real, large, repeatable saving, and it is why iPhones have recorded in HEVC by default for years.

The complication is licensing rather than technology. H.265 has a tangled patent-pool situation that made browser vendors reluctant, so support arrived late and unevenly. It is broadly playable now — Safari, Edge and Chrome all handle it on hardware that supports it — but "on hardware that supports it" is doing real work in that sentence. Older laptops and cheaper Android devices without an HEVC decoder either play it badly or not at all, and some older Windows installs still want a paid extension from the Microsoft Store.

Encoding is perhaps 3–5× slower than H.264 in software, though most modern chips have hardware HEVC encoders that erase most of that.

Use it for footage you are archiving, or for a platform you know supports it. Be careful about emailing it to a stranger.

VP9

Google's royalty-free answer to H.265, and roughly comparable to it in efficiency — usually a little behind on hard content, occasionally ahead. If you have watched anything above 1080p on YouTube, you have watched VP9.

Because it is royalty-free, browser support arrived early and is now universal in practice. Support outside browsers is the weak spot: plenty of TVs, set-top boxes and desktop players handle it poorly, and it usually lives in a WebM container that some editing software refuses.

Software encoding is slow — slower than H.265 for similar results.

AV1

The current best compression by a clear margin: roughly 30% smaller than H.265, so around 50% smaller than H.264, and it holds together at very low bitrates where the others have collapsed into blocks. It is royalty-free, backed by essentially the whole industry, and it is what Netflix and YouTube increasingly deliver.

Two real costs. First, software encoding is slow — historically dramatically so, and although modern encoders have narrowed the gap enormously, it is still the slowest option here by some way. Second, hardware decoding only appeared in chips from about 2020 onward. On a device without it, AV1 playback falls back to the CPU, which works on a laptop and drains a phone.

Use AV1 for video you serve from your own site, where you control delivery and can offer a fallback. It is a poor choice for a file you hand to someone whose device you have never seen.

The comparison in one place

• Size at equal quality — H.264 100% · H.265 ~55% · VP9 ~58% · AV1 ~40%
• Plays everywhere — H.264 yes · H.265 mostly · VP9 browsers yes, devices patchy · AV1 recent devices only
• Encoding speed — H.264 fast · H.265 moderate · VP9 slow · AV1 slowest
• Licensing — H.264 and H.265 patent-encumbered · VP9 and AV1 royalty-free

Codec and container are not the same thing

This trips people up constantly. MP4, MKV and WebM are containers — boxes that hold a video stream, one or more audio streams, subtitles and metadata. H.264, H.265 and AV1 are codecs — the rules the video stream inside was encoded with.

An .mp4 file can contain H.264, H.265 or AV1. Two files with the same extension can therefore behave completely differently, which is why "it's an MP4, why won't it play?" is such a common and such a reasonable question. The extension tells you the box; it says nothing about what is in it.

Rough guidance: MP4 for anything you send to another person, WebM for VP9 or AV1 on your own website, MKV when you need multiple audio tracks or subtitle streams and only your own player has to open it.

What to actually pick

• Sending to a person, a client, a WhatsApp group → H.264 in MP4. Not worth the risk.
• Uploading to YouTube, Instagram or TikTok → H.264 in MP4, at a generous bitrate. They re-encode everything you send anyway, so give their encoder clean input rather than a small file.
• Hosting on your own site → AV1 or VP9 in WebM, with an H.264 MP4 as the fallback source.
• Archiving your own footage → H.265, or AV1 if you have the patience. Half the storage for footage you will rarely re-encode.
• Editing → whatever your editor is happiest with, usually H.264. Long-GOP HEVC is miserable to scrub through.

Our video converter handles all of these in the browser using a self-hosted FFmpeg build, so a conversion is a real re-encode with real settings rather than a queue on somebody else's server.

The rule that outlives all of this

Convert from the best copy you have, once. Every re-encode is generational loss, and no codec — however modern — reconstructs detail that a previous encode discarded. Transcoding an already-compressed H.264 file to AV1 gives you a smaller file that inherits every artefact of the original. Going back to the camera original and encoding to AV1 gives you a smaller file that looks better than either.