Build a CSS gradient and choose the colour space it is interpolated in, with the colour it keeps through the middle measured and shown.
Initializing in your browser…
Design a CSS button and see every state measured against WCAG on the page colour you name: resting, hover, active, focus and disabled, plus the focus ring and the border.
Pick a colour and read it back in ten notations, every one checked to parse back as the same colour. WCAG contrast ratios, the nearest CSS colour name, and colour vision simulation.
Design complex box shadows with multi-layer support, inset shadows, visibility toggle, layer reordering, opacity control, and 12 professional presets
A brand gradient runs from a blue to an orange, and on screen it has a muddy pink band through the middle that neither colour explains.
The stops
#3b82f6 at 0% #f97316 at 100%
The same two colours, measured in three spaces
space colour kept through the middle midpoint sRGB 22 percent rgb(154,123,134) OKLab 27 percent rgb(167,136,161) OKLCH 100 percent rgb(212,95,194) background: linear-gradient(in oklch 90deg, #3b82f6 0%, #f97316 100%);
The muddy band is not a rendering artefact. By default a gradient is interpolated in sRGB, which draws a straight line between the two colours through the colour cube, and the middle of that cube is grey. Sampled at 32 points and converted to OKLCH, this ramp keeps 22 percent of its chroma at the centre; the midpoint is rgb(154, 123, 134), which is the pink.
The usual advice is to interpolate in OKLab, and measured here that is worth 5 points. OKLab is a rectangular opponent space, so a straight line between two hues that are far apart still passes close to neutral. For a genuinely complementary pair it buys nothing at all: magenta to green loses 95 percent in sRGB and 95 percent in OKLab, the same number.
OKLCH is the one that fixes it, because it carries hue as an angle and chroma as its own value, so chroma never has to pass through zero on the way. The midpoint becomes rgb(212, 95, 194) and essentially all the chroma survives.
Every number here is checked against the browser rather than computed and trusted: the project tests sample the pixels Chrome actually paints for the CSS the tool hands out and compare them with the ramp the tool computed, and through the interior of the ramp the two agree to within 3 of 255 in all six spaces.
Build a CSS gradient and choose which colour space it is interpolated in. The tool measures how much colour the ramp keeps through its middle and shows the number beside the gradient, because the difference between a clean blend and a grey band through the centre is a measurement rather than a matter of taste.
A gradient is a straight line between two colours in whatever space the browser is told to use. By default that space is sRGB, and a straight line through the sRGB cube between two saturated colours on opposite sides passes near the centre of the cube, which is grey. Blue to yellow goes through rgb(132, 132, 123). The ends are what was asked for, the middle is not, and nothing in the CSS says so.
CSS Color 4 added an interpolation hint, and this tool emits it: linear-gradient(in oklch 90deg, ...). Which space to use is where the common advice is wrong, and the tool measures rather than repeats it. OKLab is usually recommended, and it helps for some pairs, but it is a RECTANGULAR opponent space: magenta is +a and green is -a, so a straight line between them still passes through a = 0, which is neutral. Measured over 32 samples against the pixels Chrome paints, magenta to green loses 95 percent of its chroma in sRGB and 95 percent in OKLab, exactly the same. The space that avoids it is OKLCH, which carries hue as an angle and chroma as its own value, so chroma never has to reach zero: that same ramp loses 43 percent, and a blue and orange pair from a real palette goes from 79 percent lost in sRGB to 1 percent in OKLCH.
So the tool measures every space for the stops you have actually chosen and names whichever keeps the most colour, rather than always saying the same thing. Six are offered: sRGB, OKLab, OKLCH, CIELAB, CIELCH and HSL, with a note on each saying what it does and, for the polar ones, which way round the hue circle the ramp travels. The numbers shown are the colour kept through the middle, how far lightness moves backwards across the ramp (which is what a visible band looks like), and the worst-case WCAG contrast against white and against black, so you can tell before shipping whether any text colour works over the whole gradient.
Every number is checked against the browser. The project tests sample the pixels Chrome actually paints for the CSS the tool hands out and compare them with the ramp the tool computed: through the interior of the ramp the two agree to within 3 of 255 in every space. At the stops themselves the difference can reach 16, because Chrome round-trips a stop through the interpolation space and gamut maps the result, which is Chrome's gamut handling rather than a difference in interpolation. A fallback gradient is also produced with no interpolation hint at all, built from 48 sampled stops, for a browser that does not support the syntax; it matches the hinted version to within 2 of 255.
The preview is painted with exactly the string that is copied, so the two cannot drift, and the project tests confirm that by comparing the computed background of the preview against the same CSS applied to a second element. Linear, radial and conic gradients are all supported, along with any number of stops, presets, and a share link that carries the whole configuration.
Pick the two brand colours, then try OKLCH. The number beside the ramp says how much colour the middle keeps in each space.
The contrast readout gives the worst case across the whole ramp, not just at the ends, which is where text over a gradient usually fails.
The fallback gradient carries no interpolation hint and reproduces the same picture from 48 sampled stops.
A visible band across a gradient is usually lightness moving backwards, and the readout gives that as a number too.
Because by default a gradient is interpolated in sRGB, and a straight line between two saturated colours on opposite sides of the sRGB cube passes near the middle of it, which is grey. Measured over 32 samples, that ramp keeps 5 percent of its colour at the centre.
Only partly, and for some pairs not at all. OKLab is a rectangular opponent space, so two nearly opposite hues still have a straight line between them that passes through neutral: magenta to green loses 95 percent in both sRGB and OKLab. OKLCH carries hue as an angle instead, and the same ramp loses 43 percent there. The tool measures your particular colours and says which space keeps the most.
In a polar space the ramp travels round the hue circle, and there are two ways round. Shorter takes the near way, which is usually what you want for two similar colours; longer takes the far way, which is how you get a rainbow between two colours that are close together.
It is supported by every current browser, but not by older ones, which ignore the whole gradient rather than falling back. The tool also produces a version with no hint, built from 48 sampled stops, which reproduces the same picture anywhere and matches the hinted version to within 2 of 255.
They are checked against the browser. The project tests sample the pixels Chrome paints for the CSS the tool hands out and compare them with the ramp the tool computed; through the interior the two agree to within 3 of 255 in every space.
Holding chroma steady while the hue turns, which is what a polar interpolation does, can leave the sRGB solid, and the browser brings those colours back in. That is why an OKLCH ramp can look flatter than expected at its most saturated point. The count is shown so it is visible rather than surprising.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.