OKLCH vs HSL: What Actually Changes When You Convert a Color Scale

Build a five-step blue scale in HSL by holding hue and saturation fixed and stepping lightness evenly - say 20%, 35%, 50%, 65%, 80%. On paper it's a clean, evenly spaced scale: every step is exactly 15 percentage points from the last. On screen, the middle steps often look bunched together while the steps near the ends look like they jump. That gap between the numbers and what the eye actually sees is the real, specific complaint that sends people looking at OKLCH.

What HSL actually optimizes for

HSL organizes color the way people describe it verbally - "more saturated," "a bit darker" - which is genuinely useful for editing one color by hand. What it doesn't do is match human lightness perception. A step from 40% to 50% lightness in HSL does not look like the same amount of visual change as a step from 70% to 80%, because HSL's lightness axis is built from a simple RGB midpoint formula, not from how the eye actually perceives brightness.

What OKLCH fixes, specifically

OKLCH's L axis is built from a perceptual model (Bjorn Ottosson's OKLab, the same reference formulas both this tool and css-gradient-generator implement), so equal numeric steps in L are engineered to look like equal steps in perceived lightness - the property a lot of people reach for HSL expecting and don't quite get. The same holds for OKLCH's C (chroma, roughly "how saturated") and H (hue): moving one number changes one perceived thing more reliably than the equivalent move in HSL.

The other practical difference is that OKLCH separates chroma from lightness more cleanly than HSL separates saturation from lightness. In HSL, pushing lightness toward the extremes (very light or very dark) automatically compresses how saturated a color can look, whether you wanted that or not - it's baked into the model. In OKLCH, chroma and lightness move more independently, so a color scale can keep a consistent amount of visible saturation across its lightness steps instead of the ends of the scale quietly desaturating on their own.

A concrete conversion

Take the blue hsl(217, 91%, 60%), this tool's own default color (the one Start fresh restores). Paste it into the HSL field here and the OKLCH field shows oklch(0.6231 0.188 259.81). Build a five-step scale from there by holding chroma and hue steady and moving L in even increments instead of moving HSL's lightness percentage - the numeric distance between steps is identical either way, but the OKLCH version is the one built to keep the visual distance identical too.

Where HSL is still the right tool

HSL is still simpler to reason about by hand for a one-off tweak ("make it 10% darker"), it needs no fallback conversation because it's supported everywhere, and for most single-color adjustments the perceptual gap isn't the thing anyone actually notices. OKLCH earns its extra complexity specifically for a generated multi-step scale, where the unevenness compounds across several steps instead of showing up once in isolation.

It's worth being honest about the other side too: OKLCH's numbers are less intuitive to eyeball. Nobody reads oklch(0.62 0.19 260) and pictures the color the way a lot of people can with hsl(217, 91%, 60%) once they've worked with hue/saturation/lightness for a while. The perceptual accuracy is a real gain for building a scale; it isn't automatically a readability gain for a single value sitting in a stylesheet.

Converting an existing HSL scale to OKLCH

The practical move isn't a redesign. Paste each existing HSL step into the converter's HSL field one at a time, read the OKLCH value each one produces, and that's the literal same set of colors, expressed in a format where the steps can then be evened out by adjusting L directly instead of guessing at what HSL's lightness numbers will actually look like once rendered.

Browser support, honestly

oklch() is valid, native CSS in current evergreen browsers - not a hypothetical syntax waiting on adoption. A browser without support won't render an oklch() value written directly in a stylesheet, which is a separate question from whether this tool can convert to and from it correctly; the conversion itself is plain JavaScript arithmetic and works regardless of what any browser can paint. When a browser genuinely can't render oklch() as CSS, the converter says so plainly next to the fields - the conversion is still correct, it's only the live CSS preview that's affected.

What this doesn't replace

Converting one color at a time between formats isn't the same job as generating a whole palette or a harmony-based color scheme from scratch - that's a different tool with a different purpose. What this does is the specific, narrower step of taking a color you already have, in whatever format you already have it in, and getting an accurate value in the format you actually need next, OKLCH included.

Try it with your own scale: paste a step into the color converter and read its OKLCH equivalent, or work through the how-to guide if you want the exact steps for converting between all four formats, not just these two.