OKLCH Color Palette Generator

What OKLCH changes

HSL is easy to reason about, but its lightness axis does not match perceived brightness. A yellow and a blue with the same HSL lightness can look completely different in brightness. That is why HSL ramps often feel uneven.

OKLCH is based on OKLab, a perceptual color space. Its L axis is designed to track perceived lightness more closely, its C axis controls chroma, and its H axis controls hue. Equal L steps look more evenly spaced.

That makes OKLCH useful for generating palettes, building dark mode ramps and keeping a family of hues visually balanced.

The three numbers

L is lightness, usually written as a percentage from 0 to 100. C is chroma, where 0 is gray and higher values are more saturated. H is hue in degrees, where 0 is roughly pink-red and 180 is roughly cyan.

Unlike HSL, chroma is not a simple percentage of saturation. The maximum chroma depends on the hue and lightness, and some combinations fall outside the sRGB gamut. That is why a value can be valid OKLCH but not displayable in every browser or monitor.

The generator converts HEX to OKLCH and lets you adjust L, C and H. It also builds a tonal ramp with evenly spaced L values so you can see the difference from an HSL ramp.

Why equal lightness steps look equal

If you take a blue and a yellow and reduce their HSL lightness by the same amount, the yellow may appear to darken faster. In OKLCH, the same L change is designed to produce a more similar perceived change.

That is valuable when a palette contains multiple hues. A chart with a blue, a green and an orange can use the same L values and feel balanced. A dark-mode ramp can move from L 95 to L 15 in even steps without one hue collapsing early.

It is not perfect. Perceived lightness also depends on the surrounding colors, the display and the viewer. But OKLCH is a better starting point than HSL for systematic palettes.

Browser support and fallbacks

Modern browsers support the `oklch()` CSS function. Older browsers may not, so a production palette should include a HEX or RGB fallback. The common pattern is to declare the fallback first and the OKLCH value second.

If you use OKLCH values in CSS variables, keep the fallback values in the same token layer. That way a component does not need to know which color syntax the browser supports.

The generator outputs HEX values alongside the OKLCH values. That makes it easy to ship a fallback without maintaining two unrelated palettes.

• Declare a HEX or RGB fallback first.
• Use `oklch()` as the progressive enhancement.
• Keep fallback and modern values in one token.
• Test in the browsers your users actually use.

A practical OKLCH workflow

Start with the brand color in HEX. Convert it to OKLCH and note its L, C and H. Build a ramp by changing L while keeping H stable and reducing C at the extremes if the color leaves the gamut.

Then check the ramp in real components. A button, a card and a muted label will reveal whether the steps are distinguishable. If two steps are too close, adjust L rather than adding another color.

Finally, check contrast. OKLCH is a color model, not an accessibility guarantee. The same WCAG ratios apply, and the final foreground/background pair still needs to be measured.