OKLCH Color Palette: Build Balanced Colors in CSS

OKLCH gives palette work three unusually useful controls: approximate perceptual lightness, chroma, and hue. It does not remove the need for judgement, but it makes many edits easier to explain. Instead of guessing which RGB channel to change, you can describe a swatch as too vivid, too dark, or too warm.

Establish a reference before changing spaces

Start with one approved accent and a neutral background. Use the colour converter to normalize a source HEX or RGB value before comparing it with an OKLCH representation in browser developer tools. Keep the original sRGB value available so you can distinguish conversion issues from intentional palette adjustments.

OKLCH is a model, not a promise that every coordinate can be displayed everywhere. Its cylindrical coordinates describe colours derived from Oklab. Lightness is commonly written as a percentage, chroma as a number, and hue as an angle. Different browsers and displays still have practical limits on which combinations they can show.

Create a small working sheet containing the original accent, two lighter candidates, two darker candidates, and a grey reference. Avoid building dozens of steps immediately. A short set reveals whether your chosen hue behaves well before you invest in a complete palette.

The MDN OKLCH reference documents the syntax. Keep it nearby when checking units, especially if values come from software that displays chroma using a different interface scale.

Separate lightness, chroma, and hue decisions

Begin by holding hue approximately constant. Change lightness first to establish the intended hierarchy: background tint, subtle fill, solid accent, and strong foreground. For an exploratory blue, lightness values around 95%, 85%, 65%, and 40% make the differences obvious enough to evaluate quickly.

Next adjust chroma independently. Very pale colours usually need lower chroma than midtones, and very dark colours can also hit display limits quickly. A fixed chroma across every lightness level often produces clipping or visually awkward endpoints. There is no universal chroma number that works equally well for all hues.

Finally, inspect hue. Some families benefit from a small hue drift as they become lighter or darker, but make that an explicit aesthetic decision. If each swatch wanders unpredictably, the result can look like several unrelated families rather than one coherent colour.

Compare the swatches at equal area. A tiny vivid chip can seem acceptable while the same colour covering half a page becomes overwhelming. Evaluate both a small action element and a broad background patch before deciding that the chroma is balanced.

Build a small role-based palette

Instead of starting with an arbitrary numbered scale, define four jobs: soft surface, border, action, and strong ink. Those roles impose different constraints. A border must remain visible against its neighbours; a surface should not overpower content; an action colour needs a readable foreground.

:root {
--blue-surface: oklch(96% 0.02 250);
--blue-border: oklch(82% 0.06 250);
--blue-action: oklch(48% 0.14 250);
--blue-ink: oklch(30% 0.07 250);
}

These values are a starting hypothesis, not a validated system. Render them in the actual page, then measure combinations. Similar lightness spacing does not guarantee equal contrast ratios, and the perceived distance between swatches is not a substitute for checking text against its background.

Use the contrast checker with rendered or appropriately converted colour values. If an action background fails with white text, changing lightness may solve the problem more cleanly than pushing chroma. Recheck the hover and selected variants rather than assuming their relationship follows automatically.

Handle gamut limits and fallbacks deliberately

Increasing chroma eventually creates a colour outside the target display gamut. The maximum depends on hue and lightness. A vivid yellow and a vivid blue therefore reach their practical limits at different coordinates. Clipping can flatten distinctions or shift the intended appearance, especially when neighbouring samples are already close together.

Use gamut-aware inspection in your design software or browser tooling. When a candidate falls outside your delivery target, reduce chroma while keeping lightness and hue as stable as practical. Do not simply approve the most saturated version visible on one high-end monitor.

For older browser requirements, place a conventional value before the modern declaration. Unsupported syntax will leave the earlier declaration intact. Test the actual browsers your product supports rather than relying on the release date of a colour feature.

The CSS Color specification describes the underlying models and gamut concepts. For production support planning, consult Can I Use as a starting point, then verify your critical combinations on representative devices. Support for syntax and identical appearance are related but different questions.

Review the palette as a visual system

Place your proposed colours beside existing success, warning, and error colours. An attractive blue accent can still interfere with an informational status colour if the two are nearly identical. Role separation matters more than mathematical neatness when users need to interpret meaning quickly.

Check several content densities: a sparse settings page, a busy list, and a chart-heavy screen. Colour balance changes with coverage. A palette that looks restrained in isolated chips may become noisy when twenty selected rows and ten badges appear together.

Document allowed pairings and intentional exceptions. The design tokens guide is useful for connecting these decisions to implementation, but keep your review focused on the colours themselves: which relationships stay stable, which values can change, and where a colour must never be used.

Save a comparison sheet with the original accent and the final role colours. Record why a chroma reduction or lightness change was necessary. That short explanation prevents later edits from restoring a visually exciting but unusable candidate simply because its coordinates look more symmetrical.

Key takeaways

• Adjust one coordinate at a time when exploring OKLCH.
• Establish roles before building a large swatch collection.
• Reduce chroma near gamut limits rather than assuming every value is displayable.
• Check real foreground-background pairs independently of perceptual spacing.
• Preserve fallbacks and document why the final palette differs from the initial experiment.