Rec. 709 or Rec. 2020 for the web?
Rec. 2020 is an HDR decision, not a quality setting.

The confusion comes from treating the colour space like a quality slider. It is a description. A tagged video file carries three colour values: which primaries the picture was mixed from, which transfer function sits between the stored numbers and light, and which matrix turned RGB into luma and chroma. Those values tell a player how to read the numbers in the file. Change the tag without changing the numbers and the player simply reads them wrong.

YouTube’s upload guidance shows how the two fit together on the web. For SDR it recommends BT.709 as the standard colour space, with BT.709 transfer, primaries and matrix. For HDR it requires a transfer function of PQ or HLG, Rec. 2020 primaries and a Rec. 2020 non-constant luminance matrix, at 10 or 12 bits. And for the case in between, BT.2020 primaries without a supported HDR transfer function, YouTube says it converts them to BT.709 at 8 bits to avoid banding. On the largest video platform, a Rec. 2020 SDR upload ends up as Rec. 709 anyway.

Note the dates. Rec. 2020 was written for ultra-high definition television, and on the web it is used in the HDR combination YouTube lists: Rec. 2020 primaries and matrix, a PQ or HLG transfer function, 10 or 12 bits. If your export has a Rec. 709 transfer function and 8 bits, a Rec. 2020 primaries tag does not turn it into that.

On uncompressed.io nothing in the upload or playback path rewrites the colour tags. There is no transcode step, so nothing converts Rec. 2020 to Rec. 709, nothing maps HDR down to SDR, and no second version of the film is made for anyone. The player is a standard HTML video element. It applies no tone mapping or colour conversion of its own; how the picture looks depends on the viewer’s browser, operating system and display.

That cuts both ways, and the honest version matters here. A correctly tagged Rec. 709 export reaches the viewer exactly as you tagged it, with no platform encoder writing new metadata on the way. But a wrong tag reaches the viewer too, and the same HDR file reaches every viewer, including viewers whose screen is not HDR. YouTube generates an SDR downconversion for those viewers, and even accepts a LUT to steer it. We generate nothing. We have not tested how browsers render an HDR file in our player across devices, so we do not claim HDR displays correctly here.

Browsers do not settle the question for you either. MDN lists the video-dynamic-range media feature, which tests whether the video plane and the output device support high dynamic range, as limited availability and not Baseline, and says the determination of what counts as high peak brightness and contrast depends on the user agent. Our player does not use it.

So the practical rule: if the film has to look predictable to a client on whatever laptop they open, upload a Rec. 709 SDR export. If you are delivering HDR to an audience that includes SDR screens and you want a converted SDR version made for you, YouTube does that and we do not. If you deliver both, grade and export both, and upload the SDR version as its own film.

For the tag itself, what the QuickTime colour atom carries and what Apple documents for an untagged file, read the QuickTime gamma shift guide. If a correctly tagged SDR film still looks flat after upload somewhere else, start with washed out colors after upload.