H.264 vs H.265: the real file size difference

How much smaller H.265 really makes a file, why the 50% figure is optimistic, what it costs in encode time, and when H.264 is still the right answer.

By Kyllian · Published · 5 min read

H.265 is the successor to H.264, and the headline claim is that it delivers the same quality at half the bitrate. That claim is defensible, frequently overstated, and — for a lot of practical purposes — beside the point. Here is the fuller picture.

What the two codecs are

H.264, also called AVC, was standardised in 2003 and is the most widely deployed video codec in existence. Every browser, phone, TV, camera and editing suite made in the last fifteen years can decode it in hardware. When you see “MP4”, the thing inside is almost always H.264.

H.265, also called HEVC, was standardised in 2013 as the direct successor. It works the same way at a high level — describing frames as differences from their neighbours — but with substantially more sophisticated machinery: flexible block partitioning down to fine detail, thirty-five intra-prediction directions where H.264 had nine, better motion compensation, and an additional in-loop filter that cleans up ringing artefacts.

All of that lets the encoder describe the same picture with fewer bits. It also makes it far more expensive to compute.

How much smaller, really

The 50% figure comes from the standardisation work and it is a real result under the conditions it was measured in. In practice the gain varies enormously with content, encoder, preset and resolution, and independent comparisons generally land somewhere between 20% and 50%.

The pattern behind the variation is consistent enough to be useful:

  • 4K and high-resolution content benefits most. H.265’s larger and more flexible coding blocks were designed with exactly this in mind, and the gain at 4K is at the optimistic end of the range.
  • 1080p typically sees a solid but less dramatic improvement, often in the 25–40% region at comparable quality.
  • Low resolutions and short clips benefit least. There is less redundancy for the extra machinery to exploit, and the fixed overheads matter proportionally more.
  • Encoder effort matters more than the codec. A well-tuned x264 encode on a slow preset can match or beat a rushed x265 encode on a fast one. Codec generation is one variable among several, not a guarantee.

The practical translation: expect meaningfully smaller, expect roughly a third rather than a half on typical 1080p material, and measure rather than assume.

What H.265 costs

Encoding time. This is the big one. H.265 is several times more expensive to encode than H.264 at comparable settings, sometimes dramatically so at slower presets. On a laptop encoding a long file, that difference is measured in hours.

Compatibility. H.264 plays everywhere without qualification. H.265 does not. Support has broadened considerably — Apple platforms handle it well, and it plays back on a wide range of modern hardware — but there are still Android devices, older machines, browsers and applications where an H.265 file gives you a black frame, audio only, or a refusal. If you are sending a file to someone whose device you do not know, that risk is real.

Licensing. H.265’s patent situation is genuinely messy: multiple patent pools with separate licensing terms, rather than the single pool H.264 settled into. That complexity is a significant part of why browser and open-source support for H.265 lagged so far behind its technical merits, and why AV1 exists.

Both are available here, and H.264 is still the default

The compressor on this site will write either one. Pick MP4 or MOV and the codec control offers H.264 and H.265; pick MKV and VP9 joins them. H.265 output is tagged hvc1 rather than the default hev1, because QuickTime and Safari refuse the latter inside an MP4 and you would otherwise get a file Apple hardware will not open.

What has not changed is which one you should pick. H.265 in WebAssembly, with no hardware acceleration and whatever device you happen to be on, is several times slower than H.264 on the same clip. On a two-minute phone video that is an annoyance; on a forty-minute recording it is an afternoon. And the result is a file some of your recipients cannot play, which for a job that usually amounts to “make this small enough to send to someone” is a bad trade at any encode speed.

So: H.265 is there when you want it, and it is the wrong default. Use it when the file is going into your own archive, on hardware you have already checked can decode it. Use H.264 for anything that leaves your machine.

There is one place where this matters in the other direction. If your source is H.265 — most recent iPhone footage is — then re-encoding to H.264 needs a somewhat higher bitrate to hold the same quality, because you are moving to a less efficient codec. You get compatibility and a smaller file than the original; you do not get the best possible ratio. The MOV page covers that case, and why iPhone videos are so large explains where the files come from.

Where AV1 fits

AV1 is the current generation, developed by the Alliance for Open Media and released royalty-free — explicitly in response to H.265’s licensing situation. It is more efficient again, typically claimed at around 30% over H.265, and browser and hardware support has grown steadily.

Its problem is encoding cost. AV1 encoders were startlingly slow at launch and remain expensive even after enormous optimisation work. For streaming platforms encoding once and serving millions of times, the economics are obvious. For someone compressing a clip to send to a colleague, they are not.

Choosing

Use H.264 when the file is going to someone else, when it needs to play on unknown hardware, when you are encoding on a laptop and care about finishing, or when the source is already H.264 and you are only reducing size. This covers most cases.

Use H.265 when you are archiving your own footage on hardware you control, when the source is 4K, and when the storage saving compounds across many files. A fast machine or a hardware encoder makes it pleasant; a browser tab makes it slow but possible, and for one or two files that is a fair way to spend the wait.

Use AV1 when you are encoding once and serving many times, and you have the time to spend.

Try it on your own file. The encode runs in this tab, so nothing is uploaded.

Try the compressor