Documentation, not folklore
Search this question and you will find confident answers in both directions. We read the primary documents today: the Chrome feature entries, the Edge codec table, the Firefox release note, the WebKit posts, Apple's specs and the Windows decoder spec. Not one of them says whether a 10-bit 4:2:2 HEVC file decodes in a video element. This page shows you exactly what each vendor does publish, and what to do with a 4:2:2 master in the meantime.
No credit card required. Cancel any time.
Updated September 2026
The short answer
10-bit HEVC in the Main10 profile at 4:2:0 is documented, and it decodes on the platforms each vendor names. 10-bit 4:2:2 is documented by nobody, in either direction. Anyone telling you flatly that it plays, or flatly that it does not, is guessing.
That is not a hedge. It is the result of reading the primary documents rather than the forum threads. Chrome publishes a feature entry for HEVC hardware decoding with a platform list and no profile list. Edge publishes a codec table that calls HEVC conditionally supported. Firefox publishes one line in a release note. WebKit names HEVC among the video tracks it handles. Apple’s Mac specifications list the codecs the media engine accelerates and never name a chroma format anywhere. None of those five documents contains the string 4:2:2 in the context of browser decoding.
There is exactly one primary document in the whole stack that pins down profiles and chroma formats, and it is the Windows Media Foundation HEVC decoder specification. It lists 4:2:0 chroma only. That is the strongest published signal that exists, and it still is not a statement about Chrome on a Mac or Safari on an iPad, so it does not settle the question either. It narrows it.
The one place 10-bit 4:2:2 HEVC appears in Apple’s own documentation is the Compressor 4.6.1 release note, which added the ability to encode to HEVC 10-bit 4:2:2 on Apple silicon Macs running macOS Monterey 12.3 or later. That is an application encoding feature. It says Apple silicon can produce the format. It says nothing about whether a browser will decode it, and it is quoted as if it did all over the web.
What “not documented” means in practice
Why the question comes up at all
Chroma subsampling is how much color information survives next to the luma. It is the reason a 4:2:2 master keys and grades better than the file you send a client, and the reason the file you send a client is smaller.
4:4:4
Every pixel keeps its own color sample. Mastering and VFX grade.
4:2:2
Color halved horizontally. The broadcast and ProRes HQ standard.
4:2:0
One color sample per 2 by 2 block, 75 percent of the color discarded. What every consumer platform streams.
Grey squares are pixels. A colored dot means that pixel carries its own color information; pixels without one borrow a neighbor’s.
Broadcast and mastering formats sit at 4:2:2 for good reasons: cleaner keys, cleaner secondary grades, less chroma smearing on saturated edges. ProRes 422 is named for it. Plenty of cameras record 10-bit 4:2:2 internally, and plenty of finishing pipelines never leave it. So the moment you have an HEVC export from that pipeline, the question is reasonable: can the client just open the link.
Delivery went the other way. Every consumer streaming path standardized on 4:2:0, and the documentation followed the delivery. YouTube’s recommended upload settings specify 4:2:0 chroma subsampling outright. The Windows decoder spec lists 4:2:0 only. Apple’s HLS authoring specification names HEVC Main 10, a profile that is defined at 4:2:0. The silence around 4:2:2 in browser documentation is not an oversight; it reflects a delivery chain that was never designed for it.
Vendor by vendor
Every cell below is what the vendor publishes, read today. Where a vendor is silent, the cell says so instead of filling the gap with an inference.
Quoted phrases are verbatim from the vendor pages listed in the sources, all fetched 4 September 2026. A blank was never filled by inference: where a vendor publishes nothing on a row, the cell says so. Edge and Chrome and Firefox on Windows all reach HEVC through the operating system's decoder, which is why the Windows specification below carries so much weight for anything you send to a Windows client.
The only document that pins it down
Microsoft publishes the input and output constraints of the Media Foundation H.265 decoder in plain terms. Because Edge routes HEVC through it, and because Windows is most of the machines your clients sit at, this is the closest thing to a written contract about HEVC playback that anyone in the industry has.
4:2:0
chroma formats
The spec lists 4:2:0 only. No 4:2:2, no 4:4:4.
3
profiles accepted
Main, Main Still Picture and Main10. 10-bit input must declare Main10.
4096 x 2304
maximum resolution
Minimum 48 by 48. Output subtypes NV12 and P010.
1920 x 1088
guaranteed DXVA ceiling
Above it, hardware if the device supports it, software decode otherwise.
Read those four numbers together and a picture appears that almost nobody writing about this online mentions. The chroma line is the decisive one for this page: the only official document that names chroma formats for HEVC playback names one, and it is 4:2:0.
The resolution ceiling matters more than it looks. UHD at 3840 by 2160 and DCI 4K at 4096 by 2160 both fit under 4096 by 2304, so a normal 4K delivery is fine. Anything above 4K is not: no 5K, no 6K, no 8K through that decoder. If your deliverable is an open-gate or large-format master and the client is on Windows, the resolution is a harder wall than the codec.
The DXVA line is the one that bites in practice. Hardware acceleration is guaranteed only to 1920 by 1088. Above that, the documentation says hardware is used if the device supports it, and software decode otherwise. Software decoding a 10-bit 4K stream at a high bitrate is exactly the situation where a client reports that the video is choppy, the fan is loud and nothing is obviously broken. That is not a corrupt file. That is a decoder falling back.
One thing the spec does not say
What to do about it
The practical consequence is simple. You can hand over a 10-bit Main10 4:2:0 file and point at two vendor specifications if anyone asks why you chose it. You cannot do that with 4:2:2, so treat it as a machine-specific gamble and settle it with fifteen minutes of testing rather than an assumption.
The 4:2:2 candidate you want to send, and a 10-bit Main10 4:2:0 export of the same master at the same bitrate. Making the fallback now costs one render and removes all the pressure from the test.
Keep the fallback in the library, unshared. It exists so that a failed test costs a message rather than an evening.
Ask your client to open it on the exact computer and browser they will use for the review, scrub to a named timecode, and tell you one of four things: it plays, it is black with audio, it stutters, or it will not start. Ask which browser and whether it is a Mac or a PC. Those two facts explain most results.
You are not going to fix another company's decoder. Switch to the Main10 4:2:0 link, note the machine that failed, and keep the 4:2:2 file as the download for whoever is finishing. The test result is worth keeping: the same client will be reviewing on the same machine next time.
One nuance worth carrying. A file that fails on a client’s laptop and plays on yours tells you nothing about the file. It tells you the two decoders differ, which is the documented state of the world. Test on the target machine or the test does not count.
Our side of it
The reason this page can be blunt is that we have nothing to protect here. We do not transcode, so we have no ladder whose behaviour we would have to defend, and no re-encode that could quietly rescue a difficult file either.
Byte for byte. A 10-bit master stays 10-bit, a 4:2:2 file stays 4:2:2, nothing is normalized on the way in. That is the product. It also means the decode question belongs entirely to the viewer's browser, and for an undocumented format we will not promise a result we cannot see.
MP4 or MOV, with H.264, HEVC or AV1, up to 50 GB a file. Uploads are resumable, survive navigation and heal through network hiccups. ProRes 422, ProRes 4444 and DNxHR are hosted for client download rather than streamed, because browsers do not decode them.
There is no softer rendition to fall back to, so a slow connection buffers instead of silently switching your grade for a mushy one. Nobody ever sees a version of your film you did not make. Nobody gets rescued by one either.
Playback depends on the viewer's hardware decoder. In practice the band where consumer machines stay comfortable is around 300 to 400 Mbps. That is an engineering caveat about their hardware, not a limit we impose, and it sits far above what any streaming ladder delivers.
So the honest summary of our position: whatever you upload is what your viewer’s browser is asked to decode. For H.264, for AV1 and for 10-bit HEVC in Main10 at 4:2:0, that is a well documented ask. For 10-bit 4:2:2, it is an ask nobody has published an answer to, and a hosting platform claiming otherwise is telling you about its marketing, not about your client’s machine.
When we are the wrong answer
If what you need is a file that plays the first time, on every device your client owns, with no test and no fallback link, the answer is still H.264 in High Profile, 8-bit, 4:2:0. It is what YouTube’s recommended upload settings specify. It is what Apple’s HLS authoring specification names for maximum compatibility. It is the one codec Edge’s own support table lists as supported outright, where HEVC carries a qualifier and H.264 does not. Nothing on this site changes that, and pretending otherwise would be the same guessing we just spent a page criticising.
The same goes for adaptive delivery. A platform that transcodes your upload into a ladder of renditions and switches between them on the fly is doing real, difficult engineering, and it buys something we do not offer: a viewer on hotel Wi-Fi sees a smaller version instead of a spinner. If your audience is the general public on unknown connections, that trade is worth making and a transcoding platform is the right tool.
What we are for is the other case: a small number of viewers you chose, watching work whose quality is the deliverable, on machines you can name. For that reader, a file served untouched at 150 or 200 Mbps is worth more than a ladder, and a documented Main10 4:2:0 export is worth more than an undocumented 4:2:2 one. Keep the 4:2:2 file for the grade and the archive. Read more about what survives an upload in 10-bit video hosting and video hosting that does not compress.
Questions
That is not documented. Chrome publishes that HEVC hardware decoding shipped in Chrome 107 on platforms where hardware decoding is available, and it names those platforms. It does not publish a profile list, a bit depth or a chroma format. So there is no vendor statement to quote in either direction, and we will not invent one. Test the actual file on the actual machine, and keep a Main10 4:2:0 version of the same export ready.
Main10. The Windows Media Foundation HEVC decoder documents the Main, Main Still Picture and Main10 profiles, states that 10-bit input must declare Main10, and lists 4:2:0 chroma only. Apple's HLS authoring specification requires HEVC Main 10 Profile for streams delivered to Apple devices. Between those two you can deliver a 10-bit Main10 4:2:0 file with real confidence. Neither document mentions 4:2:2.
Because your client may not be. Edge routes HEVC through the Windows Media Foundation decoder, and its own codec table calls HEVC conditionally supported, requiring a valid HEVC Video Extension and a working decoder path. That spec is the only place in the industry where profiles, chroma formats and resolution ceilings for HEVC playback are nailed down in writing, so it is the closest thing anyone has to a contract about what a browser will accept.
Rarely. 4:2:2 earns its keep in the grade, in keying and in compositing, where the extra chroma resolution is doing work. On a review link the viewer is judging a cut, and the risk of a black frame on their machine costs more than the chroma gains. Keep the 4:2:2 file as the download or the master, and send a Main10 4:2:0 export for the browser.
No. We never re-encode. The file is stored and served exactly as uploaded, which is the whole point of the product, and it also means playback is entirely the viewer's decoder's business. For a documented format that is a good trade. For an undocumented one it means we cannot promise a result, and we will not. ProRes 422 and DNxHR are hosted for client download rather than streamed, for the same honest reason.
H.264 in High Profile, 8-bit, 4:2:0. It is what YouTube's own recommended upload settings specify, and Apple's HLS authoring specification names H.264 High Profile Level 4.1 or lower for maximum compatibility. It is the boring answer and it is the correct one when the delivery has to work the first time on an unknown machine.
Yes, and they are published. The Windows HEVC decoder documents a minimum of 48 by 48 and a maximum of 4096 by 2304. UHD at 3840 by 2160 and DCI 4K at 4096 by 2160 both fit under that ceiling; 5K, 6K and 8K do not. The same page states that the maximum guaranteed resolution for DXVA hardware acceleration is 1920 by 1088, above which hardware is used if it can and software decode otherwise.
uncompressed.io stores and serves the exact file you upload. Nothing is re-encoded, so a 10-bit master stays a 10-bit master. MP4 or MOV, H.264, HEVC or AV1, up to 50 GB a file.