OKLCH Gradient Generator

—

Why a gradient that looks fine in numbers can still disappoint on screen

OKLCH describes a color as lightness, chroma and hue, and a gradient walks a straight line through that space between your stops. The problem is that sRGB — the gamut almost every screen still has to answer to — isn't a cube in OKLCH terms. Its ceiling, the maximum chroma it can hold, rises and falls with both lightness and hue. A gradient can start and end safely inside that ceiling and still cross a stretch in the middle where the ceiling dips below the chroma the straight line calls for. The browser has no choice but to gamut-map that stretch to something else — usually a less saturated color at the same lightness and hue — and nothing about the two endpoints you typed would have warned you.

What the charts on this page are for

The lightness and chroma curves plot exactly what the CSS renders, sampled along the gradient's own axis (distance along the line for a linear gradient, the radius for a radial one, the angle for a conic one). The chroma curve is drawn against a filled ceiling — the largest chroma the target gamut can hold at that exact lightness and hue, computed by a binary search rather than read from a table. Wherever the curve pokes above the fill, that stretch is out of gamut, and the verdict line above the gradient states the percentage, the range and the peak amount by which it overshoots.

The sRGB gamut ceiling, by hue

"Ceiling" is a specific number: the largest OKLCH chroma a gamut can hold at a given lightness and hue before the color falls outside it. It isn't flat — it rises and falls with hue at any fixed lightness, which is the whole reason a straight-line gradient can leave the gamut in the middle even when both ends are safely inside it. The table below is generated by this page's own gamut-ceiling search at L = 0.5, the same binary search the chroma chart runs live, not a number copied from anywhere else.

Read a row as: at lightness 0.5, sRGB cannot hold more chroma than this at this hue — ask for more and the browser has to gamut-map it to something else. Display-P3's column is consistently higher, which is the numeric version of "P3 screens can show more vivid color at the same lightness." This is also why a fixed #chroma value that looks vivid at one hue can look washed out or clipped at another — the ceiling it's fighting isn't the same number.

Why an OKLCH gradient can sometimes look worse than an sRGB one

The case for OKLCH is usually the one this page makes with its own default: a straight line in a perceptually uniform space skips the muddy grey dip that a straight line in sRGB produces between complementary hues. But the reverse can happen too, and it's worth stating plainly rather than only ever making the favorable case. If both of your stops already sit close to the sRGB hull, the straight line sRGB draws between them can stay inside the gamut the whole way, while the straight line OKLCH draws between the same two colors can bow out through a region of higher chroma and clip. OKLCH's line is straighter in a perceptual sense, not in an sRGB-shaped one — and a gamut that isn't sRGB-shaped is exactly what makes the two lines diverge. Toggle "Compare: sRGB interpolation of the same stops" below the charts to see whether that's happening to your gradient specifically, rather than assuming either space always wins.

Three different defaults, and the one this page always states

A bare CSS gradient with no interpolation hint doesn't default to sRGB the way many people assume — it defaults to Oklab, per CSS Color 4 §13.2, and sRGB is only what you get as a web-compatibility exception when every single stop is a legacy color syntax (a hex code, rgb(), hsl() or a named color). Write linear-gradient(oklch(0.7 0.1 30), oklch(0.7 0.1 200)) with no in keyword and you already have an Oklab gradient, not an sRGB one. Tailwind CSS v4's gradient utilities default to Oklab as well, and take /oklch, /srgb, /hsl and the four hue-arc keywords as modifiers — but only on the class-name form; an arbitrary value like bg-linear-[120deg]/oklch silently produces no CSS at all, and has to be written bg-linear-[120deg_in_oklch] instead. This page never relies on any of those three defaults — every export states in oklch explicitly, which is the only way the CSS says what it means regardless of which stops it contains.

Browser support, with the dates that matter

The in <color-space> interpolation-method syntax used throughout this page shipped later than the oklch() color function itself in every major engine — which is the actual cause behind "the color works but the gradient looks wrong" reports. Support lands per space, not all at once: Chrome shipped in oklch in Chrome 111 (7 March 2023), Safari in Safari 16.2 (13 December 2022) and Firefox in Firefox 127 (11 June 2024) — a full year after Firefox had already shipped the color function it interpolates. in display-p3 and in rec2020 arrived later still in Chromium, so support is feature-detected per space here rather than printed as one version number for all ten interpolation spaces. When your browser can't render the hint, the live preview swaps to the pre-sampled fallback below and says so — the CSS output itself doesn't change, because it's still correct for a browser that supports it.

The derived sRGB fallback, and how the number is earned

Engines without the in oklch interpolation syntax, and SVG (which has no OKLCH gradient primitive at all — SVG 1.1's <linearGradient> only ever interpolates in sRGB), need a pre-sampled stop list instead of the live interpolation hint. Rather than picking a stop count in advance the way every other gradient tool in the field does — 12, or 8, or a "precision" slider with no stated consequence — this page samples the true OKLCH path at 512 or more points, then searches for the smallest stop count whose worst-case color difference (ΔE_OK, the OKLab-space color-difference metric) from that true path stays under a threshold set well inside the ~2.0 just-noticeable-difference mark. The Fallback tab prints the count it found and the measured error side by side — for example 42 stops · max error 0.31 ΔEOK — so the number is auditable rather than asserted.

Doing this in code

Everything on this page also exists as a library if you'd rather compute it in a build step. Each option makes its own choice about gamut mapping, which is worth knowing before you compare numbers between them:

// culori — clips to the destination gamut by default; use displayable()
// or a mapping mode explicitly if you need CSS Color 4's chroma-reduction behavior.
import { oklch, formatCss, displayable } from "culori";
const c = oklch("oklch(0.72 0.19 250)");
console.log(displayable(c)); // false if it's outside sRGB

// colorjs.io — implements the CSS Color 4 gamut-mapping algorithm this page also
// follows (reduce chroma at fixed L and H, not per-channel clipping).
import Color from "colorjs.io";
const inGamut = new Color("oklch(72% 0.19 250)").inGamut("srgb");

// postcss-easing-gradients — eased (non-linear) gradient stops as a PostCSS plugin,
// in sRGB rather than OKLCH; useful once you've picked stops here and want easing too.

Common use cases

• Checking whether a brand gradient stays inside sRGB before shipping it
• Picking the right hue arc for a sweep that should go the long way around the wheel
• Getting a Tailwind v4 utility class with the correct interpolation modifier
• Producing a measured, not guessed, sRGB fallback stop list for older browsers or SVG
• Understanding why a wide-hue gradient looks flat in the middle in a way a narrow one doesn't