OKLCH Color in Design: Why Perceptual Color Space Changes How You Build Palettes

OKLCH is a perceptual color model that maps color values to how humans actually perceive them — unlike HSL, which is based on screen geometry. Equal numerical differences in OKLCH produce equal perceived differences in lightness, chroma, and hue, enabling designers to build color scales, harmonics, and gradients that work visually without requiring constant manual correction. Understanding OKLCH changes how designers build systematic color.

OKLCHColor SpaceAdvanced

Key points

HSL (Hue, Saturation, Lightness) is the most common color model in web design. It is based on a mathematical transformation of RGB values, which are themselves based on how screens produce light rather than how humans see it. The result: equal HSL lightness values do not look equally light across all hues. A yellow at HSL(60, 70%, 50%) looks much brighter than a blue at HSL(240, 70%, 50%) — even though both have 50% HSL lightness. This perceptual inequality means that building a color scale in HSL by incrementing lightness values produces steps that look uneven: some steps appear larger than others depending on the hue involved. OKLCH solves this problem by using lightness and chroma values derived from how human vision works rather than how screens work.

In OKLCH, the three parameters are: L (perceptual lightness, 0–1 or 0–100), C (chroma, roughly 0–0.4+), and H (hue in degrees, 0–360). Equal L values produce equally bright colors regardless of hue — a yellow and a blue both at L:0.65 will look comparably bright to human observers. Equal C values produce equally saturated colors regardless of hue — something that HSL cannot achieve because different hues have different maximum achievable saturation. This perceptual uniformity is what makes OKLCH useful for systematic design: building a 9-step lightness scale in OKLCH produces visually even steps without manual correction, and building a harmonic palette with equal C values produces colors with equal visual weight.

OKLCH is supported in modern CSS via the oklch() color function, which means it can be used directly in production code without preprocessing. The syntax is: oklch(0.65 0.18 240) for a medium-lightness, moderately saturated blue. Browser support as of 2025: Chrome/Edge, Firefox, and Safari all support oklch() natively. Figma supports OKLCH via the color picker's 'OKLCH' mode in recent versions. Design tools that do not natively support OKLCH can use converter tools (oklch.com, bottosson.github.io/posts/oklab) to find OKLCH equivalents for any HSL or HEX color. The workflow: design and specify colors in OKLCH; export to HEX or HSL for tools that require it.

Building a lightness scale in OKLCH vs HSL

The practical difference between OKLCH and HSL scales becomes immediately visible when building a tonal scale. In HSL, building a 9-step scale for cobalt blue by incrementing lightness from 10% to 90% in equal steps produces visually uneven results — the jumps in perceived brightness vary substantially between steps. In OKLCH, building the same scale by incrementing L from 0.15 to 0.92 in equal steps produces visually even steps. The design implication: OKLCH scales require no manual correction for perceptual evenness. The numbers produce the right visual result. This makes OKLCH especially valuable for design systems where colors are generated programmatically — a loop that increments OKLCH L values produces a usable scale; the same loop in HSL requires a lookup table or hue-specific adjustments.

Equal-chroma palettes for visual harmony

One of the most powerful uses of OKLCH is building multi-hue palettes where all colors share the same C (chroma) value. In HSL, colors at equal saturation across different hues look unequally saturated because the hue affects the maximum achievable colorfulness. In OKLCH, colors at equal C value look equally saturated regardless of hue. This enables a new type of palette construction: choose your hues (e.g., cobalt H:240, emerald H:155, amber H:70, rose H:10), set equal C values (e.g., C:0.16 for a muted palette, C:0.25 for a rich palette), and adjust L to your desired lightness — the result is a set of colors that carry equal visual weight and feel harmonically matched without requiring manual balancing.

OKLCH gradients: solving the gray-band problem

CSS gradients default to sRGB interpolation, which produces the notorious 'gray band' artifact between complementary or contrasting hues. When transitioning from orange to blue in sRGB, the midpoint colors lose chroma and approach a gray — because the interpolation travels through the low-saturation center of the RGB cube. OKLCH gradients avoid this by maintaining chroma throughout the interpolation. In CSS, specify `background: linear-gradient(in oklch, oklch(0.65 0.20 70), oklch(0.58 0.22 240))` to produce an orange-to-blue gradient that stays saturated through the midpoint. The OKLCH gradient travels around the hue circle rather than through the gray center, producing a richer, more vibrant transition.

Migrating an existing color system to OKLCH

For design systems already built in HSL, migrating to OKLCH is a phased process. Phase 1: Convert existing palette values to OKLCH using a converter tool and document the OKLCH coordinates alongside the existing HSL/HEX values. This establishes the OKLCH coordinates without breaking anything. Phase 2: Add OKLCH-based versions of any new scale steps or palette additions, allowing the system to grow natively in OKLCH while existing values remain in their current format. Phase 3: Update CSS custom properties to use oklch() for new tokens and gradually replace existing tokens as they are touched in normal design system maintenance. Full migration is not always necessary — even partial OKLCH adoption for scale generation and gradient specification produces significant quality improvements over a pure-HSL approach.

Practical next step

Move from the guide into a concrete palette lane

Guides explain the use case. Collections prove the taste. Packs handle the export and implementation layer.

Browse packs More guides

Related guides

Mobile Design Guide

Color for Mobile UI: Display Characteristics, Small-Screen Legibility, and Touch Hierarchy

Mobile UI design presents unique color challenges that desktop design does not: smaller screen sizes, varying ambient lighting conditions, touch targets that require different visual treatment than hover interactions, and display characteristics (OLED vs LCD, high DPI screens) that change how colors render. Designing for mobile with color requires understanding these constraints as first-class design inputs rather than afterthoughts applied at the end of a desktop-first process.

Data Visualization Guide

Color in Data Visualization: Encoding Information Without Misleading Your Audience

Color in data visualization is not decoration — it is an encoding channel that carries quantitative and categorical information. Using color poorly in charts and graphs misleads readers, creates accessibility barriers, and undermines the credibility of the data being presented. Using color well produces visualizations that communicate at a glance, remain legible across display conditions, and serve the full range of users including those with color vision deficiencies.

Color Theory Guide

Saturation and Chroma in Design: How to Control Color Intensity Without Losing Harmony

Saturation is one of the least consciously controlled dimensions in design color work. Designers often choose colors by hue first and saturation second, treating saturation as a fine-tuning variable rather than a primary design decision. But saturation is often the difference between a palette that feels cohesive and refined and one that feels random or amateurish. Understanding how saturation works across hues — and why equal-saturation colors look unequal — is essential for professional color control.