H.264, H.265 and AV1 compared

The efficiency ranking is not in dispute. At matched visual quality, for the same content:

Codec	Bitrate needed	Released	Plays everywhere?
H.264 / AVC	100% (baseline)	2003	Yes
H.265 / HEVC	~50–60%	2013	Mostly, with licensing caveats
VP9	~55–65%	2013	Browsers yes, devices patchy
AV1	~40–50%	2018	Increasingly, not universally

So AV1 can deliver the same quality in roughly half the bytes of H.264. That is a large, real difference, and it still is not the right answer for most files.

Why H.264 remains the default

It plays everywhere, with no exceptions worth caring about. Every browser, every phone, every television, every video editor, every chat app, every hardware decoder shipped in the last fifteen years. A file you hand to a colleague, upload to a form, or send to a relative will open.

That is the whole argument, and it is usually decisive. A file that is half the size and does not play is not a smaller file; it is a support conversation.

The practical cases where H.264's efficiency penalty does not matter:

• Short clips. A 30-second clip into 20MB has 5.3 Mbps available, which is plenty for 1080p in H.264. Using a better codec buys you nothing you can see.
• Anything going to a chat app. Discord, WhatsApp and the rest re-encode on their end anyway. Handing them an AV1 file means they decode it and re-encode to H.264, which is strictly worse than giving them H.264 in the first place.
• Anything someone else will edit. H.265 and AV1 are both significantly harder on an editing timeline, and some editors still refuse AV1 outright.

Where the newer codecs genuinely win

Long files at tight budgets. This is the real case. A one-hour recording into 100MB is 220 kbps, which is hopeless in H.264 and merely poor in AV1. When the bitrate per pixel is desperate, codec efficiency stops being a nicety.

Content you control the playback of. Your own website, your own app, a video you will stream rather than hand over. If you know the decoder, use the best codec.

Storage you are keeping. Re-encoding an archive from H.264 to H.265 halves it. Worth doing for a library you own and will not be distributing file by file.

The thing most comparisons get wrong

Codec efficiency figures are quoted as if they were properties of the codec. They are properties of the codec plus the encoder implementation plus how long you let it think.

A fast hardware H.265 encode can easily be worse than a slow, carefully-tuned software H.264 encode. The 50% figure for H.265 comes from reference encoders given generous time budgets. Real-time hardware encoding on a phone or a laptop GPU gets nowhere near it.

That cuts both ways and it is worth being concrete: a hardware H.264 encoder that finishes in twenty seconds is often a better practical choice than a software AV1 encode that takes eleven minutes to be 15% smaller. For a file you need to send now, that trade is not close.

What this tool uses, and why

H.264, through your browser's WebCodecs API and your machine's own hardware encoder.

The reasoning is the stack of arguments above plus one more: hardware H.264 encoders are in essentially every device made in the last decade, which means the encode runs at a speed that makes local compression genuinely faster than uploading a file to be compressed elsewhere. A software AV1 encode in a browser would be technically more efficient and would take long enough that uploading would win — which would remove the point.

It also means there is no fallback for a browser that cannot do H.264 through WebCodecs. Those get an honest "not supported here" rather than a slow path. Images and PDFs are unaffected, because neither needs a video codec.

Constant bitrate, and the overshoot problem

Worth knowing regardless of codec, because it is the thing that decides whether a file actually fits.

Encoders aim at a bitrate; they do not hit it exactly. Variable bitrate overshoots on high-motion content — which is exactly when you least want it, because the overshoot is what pushes a 19.5MB target to 21MB and fails the upload.

Constant bitrate mode is more predictable and is what you want when a hard limit exists. It still is not exact: it undershoots on low-motion content, sometimes by 25–30%, which wastes quality you were allowed.

The only reliable answer is to measure the output and correct. Encode, weigh the real file, and re-encode on an adjusted bitrate if it came in over. Compress a video to 20MB, to 50MB or to 100MB does that — and because the encode is local and hardware-accelerated, a second pass is affordable in a way it would not be if the file had to be uploaded twice.

The short version

• Handing the file to someone? H.264.
• Sending it through a chat app? H.264 — they will re-encode anyway.
• Long recording at a tight size limit? H.265 or AV1 is worth the compatibility risk.
• Publishing on your own site? AV1, with an H.264 fallback.
• Archiving your own library? H.265 or AV1.

And in every case, resolution matters more than codec at low bitrates. Dropping 1080p to 720p buys more visible quality at a tight budget than changing codec does.

FAQ

Is H.265 better than H.264?

More efficient, yes — roughly the same visual quality at 50–60% of the bitrate. Better overall depends on what you are doing. H.264 plays on everything without exception, is easier to edit, and is what chat apps re-encode to anyway. For a file you are handing to someone else, H.264's universality usually outweighs H.265's efficiency.

Should I use AV1 to make my video smaller?

Only if you control playback or the file is long and the budget is tight. AV1 is the most efficient of the common codecs, at roughly 40–50% of H.264's bitrate for the same quality, but encoding is slow, editing support is patchy, and some devices still cannot decode it. For a 30-second clip into 20MB, H.264 already has more bitrate than it needs.

Which codec gives the smallest file size?

AV1, followed by VP9 and H.265, with H.264 last. But the real-world gap is smaller than the reference figures suggest, because those figures come from slow software encoders given generous time. A fast hardware H.265 encode can be worse than a well-tuned H.264 one, and at low bitrates reducing resolution helps more than changing codec.

Why does this tool use H.264 and not something newer?

Because it encodes on your machine using the hardware encoder already in your device, and H.264 hardware encoders are effectively universal. That makes the encode fast enough that compressing locally beats uploading — which is the entire premise. A software AV1 encode in a browser would be more efficient and slow enough to remove the advantage.