OKLCH is not HSL with different labels. HSL is a simple geometric remapping of the RGB cube and its lightness axis does not match how bright colours actually look to a human eye, which is why a pure yellow and a pure blue at the same HSL lightness look nothing alike in perceived brightness. OKLCH is built from a perceptual colour model, so equal steps in its lightness value correspond much more closely to equal steps in how light a colour actually appears, which is exactly why CSS Color Module Level 4 added oklch() as a native colour function.
The whole conversion, gamma decoding, the OKLab matrices and the final polar coordinate step, runs as JavaScript in your browser with no server call and no external colour library.
Why a hex to oklch converter needs gamma decoding first
A raw hex or RGB value is gamma encoded, meaning its numbers do not scale linearly with actual light intensity, they are compressed to match how human vision perceives brightness and to use the available bits efficiently. Before any accurate colour space math can happen, each channel has to be converted to linear light using the sRGB transfer function: values at or below 0.04045 divide by 12.92, and everything above that follows c equals the quantity of the channel plus 0.055, divided by 1.055, raised to the power of 2.4.
Skipping this step is the single most common reason a hand rolled hex to oklch converter produces visibly wrong results. Treating gamma encoded values as if they were already linear shifts every computed lightness and chroma value, usually making mid tones read as darker or less saturated than they actually are, an error that compounds through every later step of the conversion.
The OKLab intermediate step
Once a colour is linear, it is transformed into an intermediate cone response space, historically called LMS, using a fixed 3 by 3 matrix published by Bjorn Ottosson when he defined the Oklab model. Each of the three resulting values is then passed through a cube root, which is the nonlinearity that gives OKLab its perceptual evenness, before a second 3 by 3 matrix converts them into OKLab's own L, a and b axes: lightness, a green to red axis and a blue to yellow axis.
This oklab to rgb conversion path is symmetric in reverse: reversing the process means undoing the second matrix, cubing each value to reverse the cube root, then undoing the first matrix to get back to linear light, and finally re applying sRGB gamma encoding to produce ordinary 0 to 255 channel values. Every step has an exact inverse, so converting hex to OKLCH and back again returns the identical original colour, aside from the tiny rounding introduced by 8 bit channel precision.
From OKLab to OKLCH: lightness, chroma and hue
OKLab's a and b axes describe a point on a flat plane, which is useful for matrix math but not very intuitive to read or adjust by hand. OKLCH converts that same point into polar coordinates: chroma is the distance from the centre of the plane, calculated as the square root of a squared plus b squared, and hue is the angle around that centre, calculated with the two argument arctangent of b and a, then converted from radians to degrees.
Lightness carries straight across unchanged from OKLab to OKLCH, since polar conversion only affects the a and b plane. The result is a colour expressed as lightness from 0 to 1, chroma typically from 0 up to around 0.4 for colours within the sRGB gamut, and hue as a familiar 0 to 360 degree angle, which is why oklch() reads almost like hsl() despite being built on entirely different, perceptually grounded maths.
Why perceptually uniform color matters in practice
A perceptually uniform color space is one where a fixed numeric change produces a roughly constant visual change, no matter what part of the space you start from. In HSL, lightening a saturated blue by 10 percent and lightening a saturated yellow by 10 percent produce very different amounts of visible brightness change, because HSL's lightness axis does not account for how differently the eye perceives different hues at the same nominal brightness.
OKLCH was specifically designed to fix that. Building a colour scale, generating accessible tints and shades, or interpolating between two colours for a gradient all produce visibly smoother, more even results in OKLCH than the equivalent operation in HSL, which is a large part of why CSS Color Module Level 4 introduced it as a first class colour function rather than leaving OKLCH as a design tool curiosity.
How this hex to oklch converter works under the hood
The forward path is: parse hex to 0 to 255 RGB, divide by 255 and gamma decode to linear sRGB, multiply by the linear sRGB to LMS matrix, apply a cube root to each of the three results, multiply by the LMS prime to OKLab matrix, then convert the resulting a and b values to chroma and hue with the polar coordinate formulas above. The reverse path undoes every one of those steps in the opposite order.
Every matrix used here is the exact set published in the Oklab colour model, not an approximation or a simplified variant, which is what keeps the round trip from hex to OKLCH and back lossless beyond ordinary floating point and 8 bit rounding.
| Colour | HEX | OKLCH |
|---|---|---|
| White | #ffffff | oklch(1 0 0) |
| Black | #000000 | oklch(0 0 0) |
| Mid blue | #3b82f6 | oklch(0.62 0.19 259) |
| Vivid red | #ef4444 | oklch(0.64 0.21 25) |
How to convert HEX to OKLCH
- 1
Enter a HEX colour
Type or paste a 6 digit hex code, or pick one from the colour input.
- 2
Read the OKLCH values
Lightness from 0 to 1, chroma typically from 0 to about 0.4, and hue from 0 to 360 degrees appear immediately.
- 3
Adjust and check the reverse conversion
Edit the lightness, chroma or hue directly to see the resulting hex code update, confirming the round trip is exact.
- 4
Copy the CSS oklch() value
Copy the finished oklch() function ready to paste as a CSS colour value.
Related tools worth bookmarking
Sources and further reading
Frequently asked questions
Common questions about the hex to oklch converter.
The oklch color space is built from a perceptual model of human vision rather than a simple geometric rearrangement of red, green and blue, which is what HSL and HSV both are. That grounding means lightness, chroma and hue in OKLCH track how a colour actually looks far more closely than the equivalent axes in HSL, particularly when comparing brightness across very different hues.
HSL is derived directly from the RGB numbers you already have, with no reference to how light actually behaves, so it operates on gamma encoded values without complaint, even though that means its lightness axis is not perceptually accurate. OKLCH is built from a model of how the eye responds to light, so it needs the gamma encoded numbers converted to linear light first, otherwise the perceptual accuracy the whole model exists to provide is lost.
Yes, aside from tiny floating point and 8 bit rounding. Every step in the conversion, gamma decoding, the two OKLab matrices, the cube root and the polar coordinate transform, has an exact mathematical inverse, so a round trip returns a hex value that is either identical to the original or differs by at most one unit in a single channel due to rounding.
For colours that still fit inside the standard sRGB gamut, chroma tops out at roughly 0.35 to 0.4 depending on hue, since more saturated colours than that simply cannot be displayed on an sRGB screen. A chroma near 0 is essentially grey regardless of the hue value, since hue has nothing to act on without chroma.
No. OKLCH can describe colours outside the sRGB gamut, particularly at high chroma, and converting one of those back to RGB produces channel values below 0 or above 255. This tool clamps those out of range values to the nearest displayable colour and flags when clamping happened, so you know the result is an approximation rather than an exact match.
Yes, oklch() is supported natively in every current version of Chrome, Firefox, Safari and Edge as part of CSS Color Module Level 4. You can paste the output from this converter directly into a stylesheet as a colour value without any preprocessing or a JavaScript polyfill.
Hue in OKLCH and hue in HSL both describe an angle, but they are measured around differently shaped colour models, so the same visual colour can land at a noticeably different angle in each. OKLCH hue tends to track perceived colour more closely, which is one of the reasons designers building accessible colour scales increasingly prefer it over HSL.