HSL to OKLCH Converter
Convert an HSL color to OKLCH for modern CSS, with a live preview. All conversion runs locally in your browser.
hsl(200, 80%, 50%)OKLCH Result
Other Formats
#19a1e6rgb(25, 161, 230)How HSL to OKLCH conversion works
HSL (Hue, Saturation, Lightness) is the cylindrical color model most CSS developers already know, but its lightness axis is not perceptually uniform — two colors with the same L value can look very different in brightness. OKLCH (Lightness, Chroma, Hue) fixes this by building on the OKLab color space, so equal steps in L, C, or H correspond to equal perceived changes in color. It is natively supported in modern CSS via the oklch() function.
To convert, this tool first turns HSL into sRGB, linearizes it by removing the sRGB gamma curve, transforms it into LMS cone response space, applies a cube root, and finally derives OKLab and then OKLCH (polar) coordinates from the result. Every HSL color is inside the sRGB gamut, so the OKLCH output never needs clamping.
Need the reverse direction or other formats? Try OKLCH to HSL, the full OKLCH Color Converter, or HSL to HEX.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Migrating an HSL palette into a perceptually uniform space.
- Producing OKLCH values so a scale can be adjusted evenly.
- Checking what an HSL colour's real lightness is.
- Comparing two HSL colours on perceptual rather than nominal lightness.
- Producing modern CSS output from a legacy palette.
Frequently Asked Questions
- Why move an existing palette to OKLCH?
- Because the HSL values encode no perceptual information, so the palette cannot be reasoned about. Converting reveals what you actually have — often that shades meant to be equally light differ by 20 points of real lightness, which is why the ramp never looked even.
- Will the colours look different after converting?
- No — the same colour is being described in different coordinates, so the rendered result is identical. What changes is what happens when you ADJUST it: a step in OKLCH lightness moves perceived brightness predictably where an HSL step does not.
- Why does the hue angle shift?
- Because the two models place hues differently around the circle. HSL's wheel is derived from RGB geometry; OKLCH's is fitted to perception, so blue sits at a noticeably different angle. The colour is unchanged — only the coordinate naming it moves.
- What does the chroma number replace?
- Saturation, but not one-for-one. HSL saturation is relative to the maximum possible at that lightness; OKLCH chroma is an absolute distance from grey. So a pale colour can read as 100% saturated in HSL and have very low chroma, which is the honest description.
- Should the codebase keep both?
- Only during migration. Two sources of truth for the same colour drift the moment one is edited, so the useful pattern is converting once, keeping OKLCH as the authored value, and generating any hex fallback from it at build time.
Common errors and gotchas
- Expecting HSL's even-looking scale to remain even in OKLCH, which usually reveals it was not.
- Reading the lightness channels as interchangeable, which they are not.
- Converting and then continuing to edit in HSL, which undoes the benefit.
- Assuming the OKLCH value stays in gamut after adjustment, which it easily may not.
- Confusing OKLCH with CIE LCH when handing the value on.