What are OKLCH colors? (opens in new tab)

The “Better Gradients” thing is dodgy.

OKLCH is a polar coordinate space. Hue is angle in this space. So to interpolate hue from one angle to another, to get from one side of a circle to the other, you go round the edge. This leads to extreme examples like the one shown:

  linear-gradient(in oklch, #f0f, #0f0)

You can also go round the circle the other way, which will take you via blue–aqua instead of via red–yellow:

  linear-gradient(in oklch longer hue, #f0f, #0f0)

The gradient shown (in either case) is a good example of a way that perceptual colour spaces are really bad to work in: practically the entire way round the edge of the circle, it’s outside sRGB, in fact way outside of the colours humans can perceive. Perceptual colour spaces are really bad at handling the edges of gamuts, where slightly perturbing the values take you out of gamut.

Accordingly, there are algorithms defined (yes, plural: not every application has agreed on the technique to use) to drag the colour back in-gamut, but it sacrifices the perceptual uniformity. The red in that gradient is way darker than the rest of it.

When you’re looking for better gradients, if you’re caring about perceptual uniformity (which frequently you shouldn’t, perceptual colour spaces are being massively overapplied), you should probably default to interpolating in Oklab instead, which takes a straight line from one side of the circle to the other—yes, through grey, if necessary.

  linear-gradient(in oklab, #f0f, #0f0)

And in this case, that gets you about as decent a magenta-to-lime gradient as you can hope for, not going via red and yellow, and not exhibiting the inappropriate darkening of sRGB interpolation (… though if I were hand-tuning such a gradient, I’d actually go a bit darker than Oklab does).

During its beta period, Tailwind v4 tried shifting from sRGB to Oklch for gradient interpolation; by release, they’d decided Oklab was a safer default.

Great post!

Also check out oklch.com, I found it useful for building an intuition. Some stumbling blocks are that hues aren’t the same as HSL hues, and max chroma is different depending on hue and lightness. This isn’t a bug, but a reflection of human eyes and computer screens; the alternative, as in HSL, is a consistent max but inconsistent meaning.

Another very cool thing about CSS’s OKLCH is it’s a formula, so you can write things like oklch(from var(--accent) calc(l + .1) c h). Do note, though, that you’ll need either some color theory or fiddling to figure out your formulas, my programmer’s intuition told me lies like “a shadow is just a lightness change, not a hue change”.

Also, OKLCH gradients aren’t objectively best, they’re consistently colorful. When used with similar hues, not like the article’s example, they can look very nice, but it’s not realistic; if your goal is how light mixes, then you actually want XYZ. More: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value....

Also, fun fact: the “ok” is actually just the word “ok”. The implication being that LCH was not OK, it had some bugs.

Aside from a few criticisms that others have already raised I think this is quite a nice introduction to OKLCH and how to use them in CSS.

With that out of the way, I'd like to go on a tangent here: can anyone explain the modern trend of not including publishing dates in blog articles? It stood out to me here in particular because the opening sentence said that "OKLCH is a newer color model" and the "newer" part of that sentence will get dated quicker than you think. The main site does mention a date, but limits it to "August 2025" so this seems like a conscious choice and I just don't get it.

[0] https://jakub.kr/

I found this to be a good article on the subject:

https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...

Along with their picker / converter here:

https://oklch.com/

Discussed on Hacker News here:

https://news.ycombinator.com/item?id=43073819 (6 months ago, 30 comments)

> In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish.

There is a very clear shift towards green in the OKLCH lightness value change example, enormously more so than any purple vibe in the HSL example.

Clearly being able to select colours of the same perceptual intensity has value, but some of the claims here as to the benefits are exaggerated.

OKLCH: a color model based on OKLab (a perceptually uniform color space) where you control Lightness, Chroma (saturation), and Hue.

"OK" because "it does an ok job" according to its creater Björn Ottosson.

Wherever you're working with colors and text/emblems, please also consider contrast and legibility: <https://apcacontrast.com/>

On the comparison between Color spaces, it's weird, my monitor from 2008 does show a difference between the Display-P3 and the sRGB purple colors, yet I didn't think it'd have such a big color range. Is there some color conversion at the browser or OS-level? (my distro/desktop enables colormgr by default).

I tried working with it but had to give it up for practical purposes. Whereas the focus with HSL is on the Lightness part and the Saturation is made to fit, OKHCL does it differently. It pushes the Chroma part to it's technical limits and abuses the Hue to make it fit, but we just do not understand Chroma intuitively. I am waiting for OKHSL where the adjustments will bu much smaller and do not lead to absurd changes in intent. I already had a discussion about it somewhere else (https://www.reddit.com/r/css/comments/1jv5f0r/hue_is_an_issu...)

My mind immediately translated OKLCH into "Oklachroma".

For historical "neat" factor, here's the original blog post that introduced the color space:

https://bottosson.github.io/posts/oklab/

Why is there no documented formula to convert to from this color space? A quick google and the best I could find is this Gist[0]. Searching for Oklab has a Wikipedia page[1].

[0] https://gist.github.com/dkaraush/65d19d61396f5f3cd8ba7d1b4b3...

[1] https://en.wikipedia.org/wiki/Oklab_color_space

That gradient example is hilarious.

With RGB you order green salad you get green salad.

With OKLCH you order green salad you get beet soup.

Nice post. OKLCH is quite handy but for writing colors in CSS I hope eventually we’ll get some form of OKHSL/OKHSV[1] so users don’t need to worry about gamut boundaries.

[1] https://bottosson.github.io/posts/colorpicker/

There is a youtuber (Gneiss Name) making educational content through the medium of Minecraft. He's made one on OKLab as well: https://youtu.be/nJlZT5AE9zY

I've not touched oklch, but I've played with oklab gradients a fair amount.

How do they (oklch & oklab) compare for different uses?

Does anyone know how this is different to the Munsell color space, which is also perceptually uniform?

Edit: I would imagine that the only way to definine a perceptually uniform color space is by tons of user testing. This is how Munsell developed his color space… specifically presenting test subjects with pairs of identical and near-identical color swatches and asking if they could tell the difference.

In this way, pairwise comparisom of similararity became the bedrock of color perception science.

Really happy about oklch. You do have to learn the hue numbers, but once you do, everything is more intuitive.

The best axis for Lightness in my opinion is still the Gray-Scale (as used back in the day for black/white/grayscale TVs).

The newer CIE colorspaces (CIECAM02 CIECAM16) seem to address the effect, that color-perception goes wild if you change background and illumination. Oklab seems to only make some fixed choice about how to include the chromatic part to lightness. I'm not so sure, how this definition of lightness is any better than grayscale (from 1931).

Seems nice. But how to pronounce it?

Creator of OKLCH on OKLCH:

https://bottosson.github.io/posts/oklab/

> The way gradients work in OKLCH is pretty different compared to sRGB. In sRGB, gradients are calculated in red, green, and blue values, which often leads to muddy midpoints and uneven brightness.

I always understood those “muddy midpoints” as a failure to properly gamma correct the interpolation between two (s)RGB colors. Is that happening here, or is the mud coming from something else?

I added oklab to emacs's color module. I initially intended to use it to make better procedural themes, but I haven't gotten to that yet. In any case, emacs version 30 has color-oklab-to-xyz and color-xyz-to-oklab functions that work with the other functions in emacs's color module to convert to/from oklab colors.

"In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish."

The OKLCH lighter shade veers off into bright cyan! I don't see HSL getting grey on the dark side.

This is fantastic, can't wait to incorporate it into my web design classes stuff.

Also, I do hope people begin to see the value of "designing toward intuition," I can't help but notice that efforts like these are exact opposite of what happened when (most of) the world forcibly converted to metric.

In the chromaticity diagram, is my Display-P3 screen mapping everything outside the triangle back into the triangle?

some nice OKLCH resources:

https://apps.apple.com/us/app/cone-color-picker-identifier/i...

https://sindresorhus.com/system-color-picker

https://evilmartians.com/opensource/oklch-color-picker

https://oklch.eerolehtinen.fi/

https://github.com/eero-lehtinen/oklch-color-picker

> It also works the other way around, where you can change the lightness value to create various color shades and there is no hue or saturation drift unlike in other color modes.

> In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish.

I see lots of automatic palette generator projects where the shades of each color are generated with OKLCH by only varying the lightness value on some chosen base color. The problem I find is if you look at popular open source palettes, the way the hand-crafted hue and saturation values vary across the shades for different hues isn't that predictable (the curve of the hue/saturation values over shades aren't straight lines or typical easing curves).

Hawking my own tool (using HSLuv with RGB for now), but you can load and compare the hue and saturation curves as they vary over shades of a color using example palettes from Tailwind 3, USWDS and IBM Carbon, plus tweak each shade to your liking:

https://www.inclusivecolors.com/?style_dictionary=eyJjb2xvci...

So I think OKLCH is a nice starting base for palettes and a quick way to generate a color you need in CSS, but I think designers will always need to tweak the hue and saturation of each shade so it looks just right as there's no single right answer you could encode into the color space.

Oklch is so cool, My website has a single hue colourscheme derived completely from the date so that every day is a new colour.

https://adithyanair.com

Thanks for this post. Hackernews is sometimes awesome for learning opportunities like this. Never heard of the model, thankful for the article.

How does oklch compare to CIELCh(uv)? I've been using that seemingly similar system to pick uniform colors.

Quote:

    colors are much more accurate in terms of 
    how humans perceive them and it makes 
    working with them much easier

This is an aim, which I am not sure fully addressed. Think of the reason why can't I get oklch or any other method of color definition in HTML to produce the "gold color" as we humans think of it.

The fundamental reason you can't get a truly convincing "gold" color using a single value in oklch, rgb, or any other color definition is because gold is a material, not a color.

What our brain perceives as "gold" is not a single, flat hue. It's a complex interplay of light, reflection, and texture.

Point is, even with sophisticated CSS involved with linear gradient it is still a challenge

See demo at https://jsfiddle.net/oyw9fjda/

---

    <style>
    .flat-gold {
      width: 200px;
      height: 200px;
      /* Using Oklch for a perceptually uniform yellow */
      background: oklch(85% 0.11 85);
    }

    .gradient-gold {
      width: 200px;
      height: 200px;
      background: linear-gradient(
        135deg,
        oklch(60% 0.1 65),   /* Dark, desaturated shadow (brownish) */
        oklch(85% 0.11 85) 45%, /* Rich mid-tone gold */
        oklch(98% 0.1 90) 50%, /* Sharp, bright highlight (almost white-yellow) */
        oklch(85% 0.11 85) 55%, /* Back to the mid-tone */
        oklch(70% 0.1 75)       /* Softer shadow on the other side */
      );
    }

    .conic-gold {
      width: 200px;
      height: 200px;
      border-radius: 50%; /* Often looks best on a circle */
      background: conic-gradient(
        from 90deg,
        #B38728, /* Darker Start */
        #FEE9A0, /* Bright Highlight */
        #D4AF37, /* Mid-tone */
        #FEE9A0, /* Another Highlight */
        #B38728  /* Darker End */
      );
    }

    .premium-gold {
      width: 200px;
      height: 200px;
      background-color: #B38728; /* Fallback color */
      background-image:
        /* Layer 1: Sharp highlight on top */
        linear-gradient(
          175deg,
          rgba(255, 253, 240, 0.6) 0%,
          rgba(255, 215, 0, 0.2) 40%,
          rgba(136, 96, 0, 0.5) 90%
        ),
        /* Layer 2: Base metallic gradient */
        linear-gradient(
          105deg,
          transparent 35%,
          #FEE9A0 48%,
          #D4AF37 52%,
          transparent 65%
        );
      border: 2px solid oklch(60% 0.1 65);
      box-shadow: inset 0 0 10px rgba(0,0,0,0.4);
    }
    </style>

    <div class="flat-gold"></div>
    <hr />
    <div class="gradient-gold"></div>
    <hr />
    <div class="conic-gold"></div>
    <hr />
    <div class="premium-gold"></div>

I was wondering about this exact subject the other day when working on some web dev task. Now I know why this way is better.

seems like a great idea, this will make working with colors so much easier

jesus fuck the whole discussion here is ptsd inducing... you need at least color accurate monitoring (including $25-30K calibrated monitor if you want to discuss rec2020-beyond) before judging if the output color looks "correct", and as correct here includes perceptually uniformity, then your monitor is crucial since light emitting technologies in the market are wildly varied.

this is _especially_ vital if you're not from color science & color correction industry, because that means you have no prior experience(s) with many problems & implications faced in the last 30 years of say, film post-production, which might have seen or solved some of these newly experienced "problems", which might've been caused by hardware choice(s) for example.

Awesome Post

HSV with extra steps?

These IP addresses being released at some point, and making their way into something else is probably the reason I never got to fully run my mailserver from my basement. These companies are just massively giving IP addresses a bad reputation, messing them up for any other use and then abandoning them. I wonder what this would look like when plotted: AI (and other toxic crawling) companies slowly consuming the IPv4 address space? Ideally we'd forced them into some corner of the IPv6 space I guess. I mean robots.txt seems not to be of any help here.