Building gradients that stay smooth in OKLCH
Why gradients look wrong in sRGB and HSL
A gradient is a path through color space, and the space decides what the middle looks like. Interpolating red to green in sRGB passes through a muddy brown-grey, because the straight line between the two RGB points cuts through desaturated colors. HSL avoids some of that but its lightness is not perceptual, so a yellow-to-blue ramp bulges bright in the middle and dips dark at the ends. OKLCH keeps lightness, chroma and hue independent, so the ramp can hold perceived brightness steady while the hue travels — the middle stays vivid instead of washing out.
The lab above interpolates in OKLCH and then samples the result into explicit HEX stops. That means the CSS you copy renders identically everywhere, including browsers without native `linear-gradient(in oklch, …)` support. If you are choosing the endpoint colors themselves, the OKLCH picker shows gamut warnings before a too-saturated endpoint gets clipped into a flat band.
Hue direction: shorter, longer and the muddy middle
Hue is a circle, so between two hues there are always two paths. The shorter arc is the safe default. The longer arc deliberately travels through intermediate hues — a sunset ramp from orange to purple that passes through pink only exists on the long path. What you want to avoid is the path that drags chroma through grey: if the midpoint of your gradient looks dead, the hue path is crossing a low-chroma region; nudge one endpoint's hue or add a deliberate middle stop with the chroma you want.
Keep total hue travel under roughly 120° for UI surfaces (cards, buttons, hero backgrounds) so the gradient reads as one surface rather than a rainbow. Multi-hue ramps have their place in data visualisation and artwork, but then each stop should be a decision, not an accident. The guide to building OKLCH scales covers the related problem of even step ramps.
How many stops, and where to put them
Two or three stops cover most interface work: a subtle same-hue sheen, an accent sweep, a themed hero. Add stops when the hue path needs steering (avoiding a murky midpoint) or when a brand gradient has named waypoints. Because the output is sampled HEX stops, more stops also means a smoother result in the browsers that interpolate between close neighbours. Evenly spaced stops in OKLCH are perceptually even, so you rarely need the manual easing tricks that sRGB gradients demand.
Using the exported CSS
Copy the generated `linear-gradient()` as-is for a background that must match in every browser, or copy individual stops as HEX/OKLCH values into design tokens. Text over gradients still needs checking stop by stop: a pair that passes at one end can fail at the other, so run the lightest and darkest regions through the contrast checker before shipping.
Where OKLCH gradients shine in product UI
Hero backgrounds, subtle card sheens, button hover ramps, chart fills, and onboarding illustrations all benefit from perceptual interpolation. Same-hue soft gradients (small chroma travel, steady L) read as premium surfaces; multi-hue ramps work for marketing when each stop is intentional. Avoid rainbow arcs on dense dashboards — they compete with data.
If you are comparing generators, note that many free tools still blend in RGB. That is why midpoints look brown on red→green ramps. Starting here and exporting hex stops keeps the perceptual path while remaining compatible with email clients and older browsers. Fairer product comparisons live on the Coolors vs Colorise Pro page.
From gradient stops to a design system
Treat endpoint colors as brand anchors: open them in the OKLCH picker to lock gamut-safe HEX, then expand into full roles in Studio. Keep the gradient as a derived asset (background token) rather than the source of truth — when the brand primary shifts, regenerate the ramp from the same OKLCH endpoints.