H.265 vs H.264 for client delivery.
File size against certainty.

Here is the short answer, before the tables. If you do not know what machine the client will open the link on, export H.264 and move on. It is the only one of the three streaming codecs with an unqualified support statement across every desktop browser MDN documents, and Android has required an H.264 decoder since Android 3.0. The bytes you save with H.265 are worth less than one call from a client who cannot see the picture.

Reach for H.265 when you know the room: a client on recent Apple hardware, an internal team on managed Macs, a reviewer you have delivered to a dozen times. Stay on H.264 when the link will travel: a public page, a list of addresses at a brand, a programmer on an unknown laptop. Nobody has ever complained that a file was too compatible.

Two patterns are worth naming. H.265 decode is frequently tied to hardware, so a machine without the right silicon is not a machine with a slow decoder, it is a machine with no documented decoder. And Windows is where the qualifiers stack up: a store extension in one browser, a paid extension for software decode in another. A client on a locked-down work laptop is not going to fix this for you.

H.264 carries one qualifier of its own, worth knowing rather than hiding. MDN notes that Firefox support for it depends on the operating system codecs, to avoid patent concerns. That is a far narrower gap than the H.265 matrix above, but no codec on the web is unconditional.

No vendor documents 10-bit 4:2:2 HEVC decode in a video element. MDN’s codec guide states browser support at the codec level only and gives no support statement that differentiates by chroma subsampling or bit depth. Android’s supported media formats page does not mention chroma subsampling at all. The one primary decoder specification among the documents checked, Microsoft’s Media Foundation H.265 decoder, lists its chroma format as 4:2:0, and the string 4:2:2 does not appear on that page.

So the correct word is “not documented”. This page will not tell you that a 4:2:2 file plays in a named browser, and it will not tell you that it fails. The storage side is settled: because nothing is ever re-encoded, the file is stored and served untouched and the exact bytes reach the client. Whether their browser builds a picture out of them is a question their machine answers.

So treat a 4:2:2 delivery export as untested. If it must play in a browser, upload an 8-bit 4:2:0 H.264 export beside it. If it is going to a colorist who will pull it into an application, the browser question never arises and the heavier file is the right one to send.

That last detail is the closest thing to a published comparison anyone has: a platform accepting three very different codecs and recommending one bitrate range for all of them. Read it as a platform declining to publish a codec ratio, not as evidence that none exists. Your own encoder and your own footage are a better guide than a number repeated on forums.

Because nothing is re-encoded here, these ceilings are not yours. A file exported above any platform target streams at its own bitrate, unchanged. The constraint that remains is the connection at the other end, which is the real argument for H.265 when you are sure about the machine.

Run the decision from that table rather than from instinct. If a smaller export would not move you down a plan or remove a storage block, the file size argument for H.265 is worth roughly nothing and compatibility wins by default. If you deliver long programmes every week and the library drives the bill, the case for H.265 is real, and worth making client by client.