Rec.2020 only defines color primaries — it doesn't say anything about brightness. Rec.2100 is the standard that completes the picture: it takes Rec.2020's primaries and specifies which transfer function carries the actual HDR signal, offering a choice of two — PQ for absolute, display-referred brightness, or HLG for relative, broadcast-friendly scene-referred brightness. When people say "this is an HDR TV signal," Rec.2100 (in one of its two flavors) is usually the actual standard they mean.
Why it's specified as a choice, not one function
PQ and HLG solve different problems. PQ needs the display to know its own peak brightness and interpret absolute code values correctly — great for mastered content like streaming and Blu-ray, where the whole pipeline is under control. HLG needs no extra metadata to look reasonable on an SDR set — better suited to live broadcast, where you can't always guarantee every downstream device understands HDR. Rec.2100 supports both rather than picking a winner, because both are genuinely the right tool for different distribution paths.
Where this fits with what we've actually built
Rec.2100-style HDR (Rec.2020 primaries + PQ or HLG) is the "native" approach video and some image formats use. It's different from the gain-map approach our Encode tool uses, which stays in the ordinary sRGB gamut and adds HDR headroom via a second auxiliary image instead of switching transfer functions entirely. Gain-map HDR is what we could actually build and verify end-to-end locally in a browser today; full Rec.2100-style HDR image encoding would need capabilities — like a real HDR AVIF encoder — that browsers don't currently expose. We'd rather ship the real thing we could verify than claim the bigger one we couldn't.