OKLCH Color Explained for UI and Design Systems

What OKLCH represents

OKLCH is the cylindrical form of Oklab. Its three main coordinates are L for lightness, C for chroma, and H for hue. In CSS, a value can look like oklch(62% 0.18 250). Lightness is expressed as a percentage or number, chroma controls distance from neutral, and hue is an angle around the color wheel.

The practical advantage is not that OKLCH makes every color decision automatically. It gives designers and developers coordinates that are better aligned with perceptual adjustments, so changing lightness across a scale is often more predictable than incrementing RGB channels or HSL lightness.

:root {
  --brand-500: oklch(62% 0.18 250);
  --brand-700: oklch(48% 0.16 250);
  --brand-100: oklch(92% 0.05 250);
}

Lightness, chroma, and hue have different jobs

These coordinates are independent enough to make systematic editing practical, but they are not independent design decisions. A very light color can only support limited chroma in sRGB, and a constant hue does not guarantee identical brand perception across every lightness.

Perceptual uniformity is a useful approximation

Oklab was designed so equal numerical changes correspond more closely to equal visual changes than legacy RGB-style coordinates. That makes OKLCH useful for generated scales, interpolation, and theme work. “Perceptually uniform” should not be read as “perfectly uniform for every person, display, or viewing condition.” Human vision is complex, displays differ, and context changes appearance.

Gamut is the main production constraint

OKLCH can describe colors that an sRGB display cannot reproduce. When a color is outside the destination gamut, the final displayed result needs gamut mapping. Simply clipping RGB channels can shift appearance in unwanted ways. For design systems targeting broad hardware, check the actual rendered result and decide whether to keep a wider-gamut value, provide an sRGB fallback, or reduce chroma.

Colorrow’s scale generator reduces chroma for steps that need to fit sRGB and reports that adjustment. That is a deliberate implementation choice for predictable fallback output; it is not the only possible gamut-mapping strategy.

OKLCH does not replace contrast testing

Two colors with very different OKLCH lightness values can still require an actual WCAG contrast calculation for text or interface use. Likewise, a mathematically tidy scale does not guarantee accessible focus indicators, status colors, or text on every surface. Build the scale first, then test the semantic pairings that the product will really use.

A practical design-system workflow

1. Start from a real base color rather than an arbitrary hue.
2. Generate light-to-dark candidates while watching chroma near gamut edges.
3. Assign the raw steps to semantic roles such as background, primary, text, and border.
4. Preview those roles in components and themes.
5. Run pairwise contrast checks for the combinations that carry text or essential UI boundaries.