Skip to content
Header image for How OKLCH Makes Better Gradients (And Why We Built Our Tool Around It)
Engineering

March 23, 2026

4 min read

How OKLCH Makes Better Gradients (And Why We Built Our Tool Around It)

B

Blue Monkey Makes

If you've ever created a gradient from blue to yellow and wondered why the middle looks like dishwater, you've run into the RGB interpolation problem. It's not a bug in your code. It's a limitation of the colour space.

Most gradient tools — and CSS itself, by default — interpolate colours in sRGB. This is the colour space your monitor uses, and it's fine for displaying individual colours. But it's terrible for blending between them, because sRGB isn't perceptually uniform. Equal mathematical steps don't produce equal visual steps.

This is the problem OKLCH solves. And it's why we built our gradient tool around it.

What "perceptually uniform" actually means

In sRGB, if you increase the green channel by 20 units, the perceived brightness change depends on where you started. Going from 0 to 20 is barely noticeable. Going from 200 to 220 is a significant shift. The scale isn't linear in terms of how your eyes process it.

OKLCH (Oklab Lightness, Chroma, Hue) is designed so that equal numerical changes produce equal visual changes. A 10-unit shift in lightness looks like the same amount of change whether you're at the dark end or the light end of the scale.

This has three practical consequences for gradients:

  1. No muddy midpoints. A gradient from blue to yellow stays vibrant throughout the transition instead of passing through grey.
  2. Predictable shade scales. When you generate shades from 50 (near-white) to 950 (near-black), each step looks evenly spaced.
  3. Harmonious colour relationships. Rotating hue by 120 degrees in OKLCH produces a visually balanced triadic palette. The same rotation in HSL produces colours that feel unbalanced because HSL's hue wheel isn't perceptually even.

How we use OKLCH in Gradient Galore

Every colour operation in Gradient Galore happens in OKLCH space. Here's what that looks like in practice.

Shade scale generation

When you pick a base colour, we convert it to OKLCH, then generate 11 shades by setting the lightness to predetermined targets (0.97 for shade 50 down to 0.14 for shade 950). We scale chroma proportionally — colours near the extremes get less chroma to avoid oversaturation at the edges.

The result is a shade scale that feels natural. The 500 shade is the "true" colour. Lighter shades are tints. Darker shades are shades. And each step is visually equidistant.

True tints, shades, and tones

Most tools generate a single lightness ramp and call it a "shade scale." We generate three separate scales:

  • Tints: Base toward white — lightness increases, chroma decreases
  • Shades: Base toward black — lightness decreases, chroma slightly decreases
  • Tones: Base toward grey — chroma decreases, lightness stays near the original

These are the classical colour theory definitions, computed accurately in OKLCH.

Colour harmony

When you generate a complementary, analogous, or triadic palette, we rotate the hue in OKLCH space. A complementary colour is +180 degrees. Analogous colours are +30 and -30 degrees. Triadic colours are +120 and +240 degrees.

Because OKLCH's hue dimension is perceptually uniform, these rotations produce harmonies that actually look harmonious — unlike HSL, where a 120-degree rotation might produce two colours that feel like they belong together and one that doesn't.

Palette-wide adjustments

The palette editor includes global sliders for hue shift, saturation scale, and lightness scale. These operate on the OKLCH values directly:

  • Hue shift rotates all colours by the same number of degrees
  • Saturation scale multiplies chroma by a factor
  • Lightness scale multiplies lightness by a factor

Because these operations happen in a perceptually uniform space, the adjustments feel proportional. Shifting hue by 30 degrees moves every colour by what looks like the same amount.

Contrast checking

The contrast checker uses relative luminance (WCAG 2.x formula) to compute ratios between any two palette colours. This part doesn't use OKLCH — WCAG is defined in terms of sRGB luminance — but the underlying conversion from hex to linear RGB reuses the same sRGB-to-linear function that feeds into our OKLCH pipeline.

The CSS connection

CSS now supports OKLCH natively. You can write:

background: linear-gradient(in oklch, #6d28d9, #0891b2);

And the browser will interpolate in OKLCH space, avoiding the muddy midpoint problem. This is a huge improvement over the default sRGB interpolation.

However, CSS colour interpolation only helps with simple gradients. For aura gradients (layered radial blobs), mesh gradients, and shade scale generation, you still need to do the maths yourself. That's what Gradient Galore does — and why the OKLCH engine is the core of the tool, not just a nice-to-have.

Try it yourself

If you want to see the difference OKLCH makes, open Gradient Galore and create a gradient from a warm colour to a cool one. Compare it to the same gradient in any tool that uses RGB interpolation. The midpoint tells the whole story.

We built this because we wanted better gradients in our own projects. The colour science made it possible. The tool makes it practical.

colour scienceOKLCHCSSgradientsdesign