Understanding Color Gamuts: sRGB, P3, and Rec. 2020

A "gamut" is simply the full range of colors a specific device, color space, or medium can represent. Every screen, printer, and color space has a boundary somewhere — a most-saturated red it can produce, a deepest green — and colors outside that boundary either get clipped or approximated. Most day-to-day web and product work never needs to think about this explicitly, because sRGB has been the safe universal default for decades. That default is now genuinely worth revisiting.

sRGB: the long-standing default, and its real limitation

sRGB was standardized in 1996 specifically to give a consistent, interoperable color space for consumer displays and the early web, and it succeeded well enough that it's still the implicit assumption behind plain hex, rgb(), and hsl() values in CSS. Its limitation isn't accuracy — colors inside its gamut render consistently — it's *size*. sRGB covers a meaningfully smaller portion of the full range of colors the human eye can perceive than modern display hardware is now capable of producing, particularly in saturated reds, greens, and cyans.

Display P3: the practical wide-gamut default today

Display P3 (based on the DCI-P3 cinema standard, adapted for consumer displays) is roughly 25% larger than sRGB in terms of representable color volume, and it's now the default gamut on the overwhelming majority of recent phone screens and a large share of laptop and monitor panels — Apple pushed early, broad hardware adoption, and other manufacturers followed. A P3 display can show saturated reds and greens that are genuinely impossible to represent in sRGB at all — not just clipped versions of the same color, but colors with no in-gamut sRGB equivalent whatsoever. CSS exposes this directly:

.wide-gamut-red {
  background: color(display-p3 1 0.1 0.1); /* more saturated than any sRGB red */
}

On an sRGB-limited display, this gets gamut-mapped to the nearest representable sRGB color automatically; on a P3-capable display, it renders as the more saturated color actually specified. This is graceful, automatic fallback, not a bug you need to handle manually — but it does mean two users can see genuinely different colors from the identical CSS if one has a wide-gamut screen and one doesn't, which is worth being aware of for any brand color where exact hue matching across devices genuinely matters.

Rec. 2020: the far larger, mostly-future gamut

Rec. 2020, defined for ultra-high-definition broadcast and video, covers a dramatically larger range than either sRGB or P3 — large enough that no current consumer display hardware can reproduce the full space, and most Rec. 2020-tagged content today is itself only using a fraction of the theoretical range. It's relevant mainly to video and HDR content pipelines right now rather than everyday web/UI work, but the color() function supports specifying it directly (color(rec2020 ...)) for the rare case where a project's source material is genuinely mastered in that space.

When gamut actually matters for a typical project

For the majority of UI and web design work, sRGB remains a perfectly reasonable default — most brand colors aren't at the extreme edge of the sRGB gamut boundary, and picking, testing, and shipping entirely in sRGB avoids any cross-device rendering inconsistency at all. Gamut becomes a genuine practical concern in narrower cases: highly saturated brand reds or greens specifically chosen to look vivid and "pop," photography and video work where source material may already be captured in a wider gamut and shouldn't be needlessly clipped down, and any product where color-accurate reproduction across devices is itself a selling point (design tools, photo editors, print-preview software).

A practical check: is your brand color near the sRGB edge?

Run your brand hex through the color converter and look at its OKLCH chroma value relative to other colors of similar hue and lightness — colors sitting very close to the maximum representable chroma for their hue/lightness combination are the ones most likely to look different across sRGB and P3 displays, or to get subtly clipped in a CMYK print conversion (a related but distinct gamut boundary problem, covered separately in print color: CMYK vs. screen RGB). A moderately saturated brand color has more room to render consistently across every gamut it will ever encounter; an extremely saturated one is making a deliberate tradeoff for vividness at the cost of some cross-device consistency, and that tradeoff is worth making knowingly rather than by accident.

Gamut and OKLCH: a genuinely useful pairing

One practical reason OKLCH has gained traction alongside wide-gamut support specifically: its coordinate system extends naturally beyond the sRGB boundary, so the identical oklch() syntax used for an ordinary sRGB-safe color also works for specifying colors in the wider P3 or Rec. 2020 range, with the browser handling gamut mapping automatically for viewers whose displays can't show the full value. This is covered from the color-math side in what OKLCH is and why it matters and from the CSS syntax side in modern CSS color functions — gamut awareness is one of several practical reasons those newer functions are worth knowing, not just a perceptual-uniformity nicety.

A worked example of gamut mapping in practice

Suppose a brand color is authored as \color(display-p3 0.95 0.15 0.1)\ — a very saturated red-orange near the outer edge of the P3 gamut. On a P3-capable screen, this renders close to the specified value. On an sRGB-only screen, the browser has to gamut-map it: the most common approach clips or compresses the out-of-range channel(s) to the nearest representable sRGB value, which for this example typically resolves to something close to pure sRGB red, \#FF0000\-adjacent, losing some of the subtle orange undertone the P3 original had. The visible difference between the two renderings is small but real, and it's the kind of gap that matters if a brand's exact hue identity is part of what's being protected (see the trademark and color-identity note in picking brand colors) — worth testing on both an sRGB and a P3 display before finalizing a highly saturated brand hex, rather than discovering the discrepancy after launch.

Video, dark mode, and HDR: where Rec. 2020 actually shows up today

Even though Rec. 2020 isn't yet a practical target for everyday UI color choices, it's worth knowing where it already matters: HDR video content, some game engines targeting HDR-capable displays, and increasingly, photography workflows that capture and edit in a wider gamut before ultimately delivering an sRGB or P3 export for the web. If your project touches any of those pipelines — embedding HDR video, or sourcing product photography shot and graded in a wide-gamut workflow — colors extracted from that source material (for instance, via the image color extractor) may already be more saturated than a typical hand-picked sRGB palette, and worth a deliberate gamut check rather than assuming they'll drop cleanly into an sRGB-based design system.