Upload an HDR master to a review link and the reaction is always the same: why does it look gray? The answer is structural, not a bug: the web is an sRGB surface - the W3C's CSS Color Module states plainly that untagged colors "must be treated as being in the sRGB color space" - and a browser video player is an SDR display pipeline with roughly 100 nits of reference white, not a tone-mapping HDR display. PQ-encoded footage shown on that surface without a tone map lands its midtones in the wrong place, and washed-out is what wrong looks like. Here is the vocabulary, the mechanism, and the fix that keeps HDR masters intact while clients review something that looks right.
The vocabulary: PQ, HLG, and the numbers
Modern HDR comes in two transfer methods, both defined by ITU-R BT.2100 (latest revision BT.2100-3, February 2025): PQ (Perceptual Quantizer, standardized as SMPTE ST 2084), which encodes absolute luminance up to a practical maximum of 10,000 cd/m², and HLG (Hybrid Log-Gamma), the backward-compatible broadcast variant. The numbers that make the problem concrete, from the ITU's BT.2408 report: SDR reference white sits at 100 cd/m², and the agreed HDR reference white is 203 cd/m² - diffuse white in an HDR grade is meant to sit just double SDR white, not at the ceiling. Consumer displays spread between those poles: VESA's DisplayHDR certification runs tiers from 400 up to 1400 cd/m² peak luminance. An HDR master therefore carries brightness an SDR pipeline physically cannot show - the question is only how sensibly it gets squeezed.
HDR10 vs Dolby Vision vs HLG
| Format | Transfer | Metadata | Where it lives |
|---|---|---|---|
| HDR10 | PQ (ST 2084) | Static: ST 2086 mastering metadata + MaxCLL/MaxFALL (YouTube's HDR spec asks for exactly these) | Default open HDR; UHD Blu-ray, streaming baseline |
| HDR10+ | PQ | Dynamic per-scene metadata | Samsung-ecosystem HDR |
| Dolby Vision | PQ | Dynamic per-shot metadata - Dolby documents "three core metadata values for each shot" plus trim-pass layers | Netflix-tier streaming, UHD Blu-ray, Apple devices |
| HLG | BT.2100 HLG | None needed (backward-compatible with SDR displays) | Live broadcast |
Why it looks washed out, mechanically
PQ codes absolute luminance: each code value means a specific brightness. An SDR display - a browser player on a 100-nit panel - has no instruction to translate that curve, so mid-gray code values land above where SDR expects them and highlights land nowhere useful. The image loses contrast, saturation looks drained, and the whole cut reads as milky. Same file, correct result on an HDR display, wrong result on an SDR one - which means the file is fine and the surface is wrong. The display-side cousin of this phenomenon (gamma mismatches shifting midtones) is in why video looks different on a review link, and the transfer-curve background is in the color-space explainer.
The fix: ship an SDR trim for review
The working pattern in HDR pipelines is to keep the HDR master authoritative and review a derived SDR Rec.709 version. The NLEs document their halves of this: Premiere Pro's color management includes automatic tone mapping that "recalculates the HDR color values so that they display consistently in the narrow Rec. 709 color space" (per Adobe's current tone-mapping documentation), and DaVinci Resolve's Dolby Vision workflow is built around trim passes - "you're only required to make a 100 nit trim pass to guide the HDR", with additional passes at other nit levels - plus an Output Tone Map setting for mapping wide-dynamic-range images to SDR output. The honest boundary: a 100-nit trim is a graded translation, not a button - HDR-to-SDR is where creative decisions live, which is exactly why it should happen in the grading tool and not be improvised by a browser.
What the platforms do
Streaming surfaces solved this same problem server-side: YouTube accepts HDR uploads (10/12-bit, Rec.2020, PQ or HLG, metadata required) and states plainly that "viewers watching on non-HDR devices will see the video as a standard dynamic range (SDR) video" - the platform, not the viewer's browser, does the conversion. A review link currently does the client-side equivalent of nothing, which is why the review copy should already be SDR when it leaves your NLE.
The review-round workflow
Version discipline makes this painless: upload the SDR trim as the review version and keep the HDR master for delivery (the delivery-side vocabulary is in the delivery checklist; export settings for review copies in what format to export for client review). Clients comment on an image that matches what they will eventually see on their own screens; the HDR master never touches a browser. If the deliverable itself is HDR-first, say so on the link - reviewers judging the SDR trim should know the contrast behavior they approve is the translation, and the master carries the rest.
FAQ
Can I upload an HDR file to a review link?
Technically the upload works, but browser playback is an sRGB SDR surface, so PQ footage displays without tone mapping and looks washed out. Ship a derived SDR Rec.709 copy for review and keep the HDR master for delivery - that is the documented pattern in HDR pipelines (trim passes at 100 nits in Resolve's Dolby Vision workflow, automatic Rec.709 tone mapping in Premiere).
Why does my HDR export look gray even on YouTube?
If the viewing device is not HDR-capable, YouTube itself shows the video as SDR - its help documentation says so directly. Gray-on-SDR-device is expected behavior, not an upload failure; check on an HDR display or the HDR-prefixed quality setting before regrading.
What is the 203-nit thing?
The ITU's BT.2408 report defines HDR reference white as 203 cd/m² - the level diffuse white (paper, white shirts) should sit at in an HDR grade, deliberately about double the SDR reference white of 100 cd/m² rather than anywhere near the display's peak.
Do I need an HDR monitor to review HDR work?
To grade it, yes - a reference HDR display is the tool the trim pass is judged on. To approve it, no: clients approve the story, pacing, and the SDR translation on ordinary screens, which is precisely why the review copy should be the SDR trim.
HDR10 or Dolby Vision - does it change the review workflow?
Not at the review-link stage: both are PQ, and both review from the same SDR trim. The difference is downstream - static vs per-shot dynamic metadata - which affects the mastering pass in Resolve's Dolby Vision tooling, not what a client sees on a browser link.