RGB to OKLCH Converter — Modern CSS Color

Building an accessible colour ramp starts with evenly-spaced lightness

Designers often build colour tokens—the 50/100/200…900 scales used throughout a design system—by holding hue and chroma constant and stepping lightness. OKLCH makes this work because its lightness (L) is perceptually uniform: stepping L by equal increments gives a ramp that actually looks evenly spaced, unlike HSL where some hues appear darker than others at the same stated lightness. This uniform stepping is why so many design tools now recommend OKLCH for building colour systems. This converter reports L and C to four decimal places and hue to two, which is ample resolution for defining token stops.

OKLCH lightness is not WCAG contrast, and that is the critical error

Here is the distinction that quietly breaks accessible colour ramps: OKLCH L and WCAG contrast ratio are completely different measurements, and one cannot stand in for the other. WCAG 2.x contrast is computed from linearised sRGB relative luminance — a weighted sum that treats green as far more luminous than blue — and then combined as (L1 + 0.05) / (L2 + 0.05). OKLCH lightness is a perceptual scale built on a different model entirely. The two curves do not track each other.

The practical consequences run in both directions. Two colours can sit a comfortable distance apart in OKLCH L and still fail 4.5:1. And two colours with identical OKLCH L can have different contrast ratios against the same background, because they differ in chroma and hue. A ramp that looks perfectly even is not thereby accessible, and an accessible pair is not thereby even-looking. These are two separate properties that happen to both involve the word "lightness".

Always check each pair against a real contrast ratio calculator

The working method is to use OKLCH to make the ramp look visually even, then measure every foreground/background pair you actually intend to use. Run them through the colour contrast checker and compare against the real thresholds: 4.5:1 for AA on body text, 3:1 for AA on large text (roughly 18pt, or 14pt bold), 7:1 for AAA on body text and 4.5:1 for AAA on large text. Non-text UI elements such as input borders and icons have their own 3:1 requirement. Measuring is not optional — visual evenness and accessible contrast are solved by different formulas and must be verified separately.

Chroma has no fixed ceiling, and the reachable maximum differs by hue

Unlike HSL saturation, which is always a percentage of some maximum, OKLCH chroma is an absolute distance with no built-in upper bound. The catch is that the highest chroma sRGB can actually display varies considerably by hue — a vivid green reaches about 0.29 while other hues top out well below that. So if you lock chroma and rotate through hues at constant lightness, some hues will fall outside the gamut while others sit comfortably inside, and the ones that fall outside get clamped on the way to a displayable colour.

The rule of thumb that follows: a lightness-locked ramp on a single hue is safe, because you are moving along an axis the gamut supports. A chroma-locked hue rotation is not, and will silently clip somewhere. If you need a full hue wheel at matched intensity, lower the chroma until the weakest hue in your set is comfortably inside the gamut, and accept that your strongest hues will be less vivid than they could be.