Convert HEX to OKLCH

HEX to OKLCH Color Converter

HEX is the most portable color format. OKLCH is the most editable.

HEX encodes red, green, and blue channel intensities, which makes the numbers compact for storage, but gives no intuitive signal about how the color will look after adjustment. OKLCH separates perceptual lightness, chroma (colorfulness), and hue angle in a space where equal numeric steps produce roughly equal perceived differences. Converting a HEX brand color to OKLCH gives you coordinates you can adjust by feel rather than by trial and error across three opaque channel values.

How the conversion works

Converting HEX to OKLCH routes through four intermediate color spaces. First, HEX decoding produces linear sRGB by undoing the gamma curve. Second, a matrix multiplication produces XYZ-D65, a device-independent space. Third, a non-linear transform produces OKLab, Björn Ottosson's perceptual model. Fourth, a polar-coordinate extraction produces OKLCH from OKLab.¹ The lightness L is the OKLab L channel (0–1 range). Chroma C is the Euclidean distance from the OKLab origin: √(a² + b²). Hue H is the angle in degrees: atan2(b, a). Consequently, the hue angle in OKLCH is not the same as the hue angle in HSL or HSV; it is measured in a perceptually uniform space rather than the raw RGB model.

Where this comes up

CSS Color Level 4 includes oklch() as a first-class color function supported in all modern browsers. Tailwind CSS v4 defines its built-in palette entirely in OKLCH, meaning design systems built on Tailwind v4 often need to express custom brand colors in that space.² Converting to OKLCH is the recommended first step before building a color scale: holding L and C constant while rotating H produces a harmonious palette of related colors, whereas the same operation in HSL produces visible lightness jumps at certain hue angles because HSL is not perceptually uniform. Figma does not yet accept OKLCH coordinates natively in fill inputs, so converting back to HEX for handoff is still a common workflow.

Edge cases and rounding

Very dark colors (L near 0) and very light colors (L near 1) produce low chroma values near 0 because the perceptual color space compresses the sRGB gamut near the white and black points. Colors outside the sRGB gamut (P3 or Adobe RGB colors) may show high-chroma or out-of-range L values in OKLCH.³ For standard web colors, all HEX values within the sRGB gamut convert without clamping. Floating-point arithmetic means a round-trip conversion may shift the last RGB channel digit by 1. Rounding differences between this converter and a CSS preprocessor plugin are typically within 1 unit per channel, which is below the threshold of visual perception.

The HEX to OKLCH pipeline in detail

Converting HEX to OKLCH passes through four color spaces, each with a specific role. First, the HEX string decodes to three 0 to 255 integers, which normalize to 0 to 1 floats. Second, the sRGB transfer function (gamma curve) linearizes these floats: values below 0.04045 divide by 12.92; values above apply the power curve. Third, a 3x3 matrix multiplication transforms linear sRGB to XYZ-D65, a device-independent space anchored to a standard illuminant. Fourth, a non-linear matrix converts XYZ-D65 to OKLab, and the final step extracts polar coordinates (L, C, H) from the Cartesian OKLab values. Every step is a fixed mathematical operation with no approximation.

Why the gamma curve matters for accuracy

Skipping the gamma linearization step is the most common error in hand-rolled color conversion code. The sRGB gamma curve means that the HEX value #808080 (mid-grey) does not represent 50% light intensity; it represents roughly 21% linear light.¹ Converting #808080 to OKLCH without undoing the gamma gives you L near 0.5, which is wrong. The correct L for mid-grey is approximately 0.53. Always apply the full sRGB-to-linear step before the matrix transformations, or your OKLCH values will be systematically biased toward higher lightness for dark colors and lower lightness for bright colors.

The bias is subtle enough that it passes a casual visual check, which is exactly why it survives in so much hand-written code. A developer who ships a half-correct converter may not notice that their dark brand colors render slightly washed out until they compare against a reference value side by side. Running the full sRGB-to-linear step removes the discrepancy entirely, so the OKLCH output matches what CSS itself computes internally when it parses a HEX value.

Choosing OKLCH coordinates for design tokens

When you express a HEX brand color in OKLCH for use as a design token, the resulting coordinates tell you how the color behaves in perceptual space. The L value shows where it sits on the lightness scale: L=0.96 (like #c8ff00) is very light, suitable for backgrounds or highlights; L=0.61 (like #3b82f6) is mid-range, suitable for primary interactive elements. The C value shows how saturated it is: C=0.24 is vivid, C=0.05 is muted. The H value shows the hue family, which you can use to find complementary or analogous colors by adding or subtracting hue angles.

Storing the canonical value in OKLCH

Store your design tokens in OKLCH and derive HEX, RGB, or HSL at build time for tools that need those formats. This keeps the authoritative value in the most perceptually meaningful space. A token defined as oklch(0.612 0.212 261.5) can produce #3b82f6 for Figma, rgb(59, 130, 246) for canvas, or hsl(217, 91%, 60%) for legacy CSS, all from the same source. If you store the canonical value in HEX and convert to OKLCH on read, you lose the perceptual precision that makes OKLCH useful in the first place.

OKLCH for programmatic color scale generation

Generating a color scale from a single HEX input is a common design system task. Convert the HEX to OKLCH first, then create variants by adjusting L while holding H and C approximately constant. A 10-step scale from 50 to 950 needs L values that are perceptually equidistant: the steps are not linearly spaced in L because human vision is more sensitive to lightness differences in the mid-range than at the extremes. Tailwind v4's built-in palette uses a carefully tuned L curve that compresses steps near the light and dark ends.

Adjusting chroma across lightness steps

Holding C constant across all lightness steps produces colors that look oversaturated at very light and very dark extremes. Reduce C by 20 to 30% for steps above L=0.85 and below L=0.30 to match the natural chroma compression of the sRGB gamut at those lightness levels. This adjustment produces a scale where every step looks like a natural shade of the same hue family rather than an artificially vivid outlier at the extremes. The exact C reduction curve depends on the hue: yellows tolerate higher chroma at light lightnesses than blues do.

When to use this

Use this when a brand color stored as HEX needs to be expressed in OKLCH for a Tailwind v4 config, a CSS Color Level 4 stylesheet, or a design system that uses perceptual lightness coordinates for color scale generation.

Examples

#c8ff00

oklch(0.960 0.241 128.2)

#3b82f6

oklch(0.612 0.212 261.5)