Why an evenly-spaced shade ramp does not look even

Building a UI palette from one brand colour usually means building a ramp: a row of lighter and darker versions, evenly spaced, that you can assign to backgrounds, borders, hover states and text. The obvious way to build one is to mix the base colour toward white for the light half and toward black for the dark half, in equal percentage steps. That is what almost every quick ramp does, and the result reliably has a problem: the dark half falls off a cliff while the light half barely moves.

What the ramp actually computes

The free Shade Generator produces nine steps from one base colour, using a mix fraction p that runs 0.8, 0.6, 0.4, 0.2, 0, -0.2, -0.4, -0.6, -0.8. For a positive p each channel becomes x + (255 − x) × p, moving that fraction of the remaining distance toward white. For a negative p it becomes x × (1 + p), which is the same idea toward black.

Feed it #4ade80 and you get, from lightest to darkest: #DBF8E6, #B7F2CC, #92EBB3, #6EE599, #4ADE80, #3BB266, #2C854D, #1E5933, #0F2C1A.

Nine steps, each exactly 20 percentage points of mix from the last. In the numbers, that is perfectly even. Now measure it.

Measuring the steps

Relative luminance is the standard measure of how much light a colour puts out: linearise each channel out of its sRGB gamma encoding, then take the weighted sum 0.2126 × R + 0.7152 × G + 0.0722 × B. Run it on all nine steps, lightest first:

0.8791, 0.7793, 0.6878, 0.6165, 0.5526, 0.3373, 0.1785, 0.0766, 0.0198

The base colour sits at 0.5526. The first step lighter moves it by 0.0640. The first step darker moves it by 0.2153 — more than three times as far, for the same 20 percentage points of mix. Keep going and the pattern holds: the four light steps together cover 0.3265 of luminance, the four dark steps cover 0.5328.

Worse, neither half is internally even. The dark steps shrink as they go — 0.2153, then 0.1588, 0.1019, 0.0568 — while the light steps grow: 0.0640, 0.0713, 0.0915, 0.0998. Nothing about this ramp is evenly spaced except the number you typed.

Why the numbers lie

The cause is the gamma encoding. An sRGB byte is not proportional to emitted light; the encoding devotes far more of its 256 values to the dark end than to the bright end, because that is where the eye can tell values apart. Halving a channel byte therefore removes much more than half the light.

So a mix that is linear in the stored bytes is badly non-linear in anything you can see. Mixing toward black cuts light fast at first; mixing toward white is already near the top of the curve and has less room to move. The two directions are running on different parts of the same curve, which is exactly why a symmetric formula gives an asymmetric ramp.

Converting to HSL does not rescue it, though it does soften it. The same nine steps in HSL lightness are 92, 83, 75, 66, 58, 46, 35, 23, 12 percent — the four dark steps take 11 or 12 points each while the four light steps take 8 or 9. There is a second effect visible there too: HSL saturation stays between 67 and 70 percent across the light half, then drops to 49 or 50 percent across the whole dark half. That desaturation is what people mean by the dark end going "muddy". The hue itself is stable, staying between 141 and 143 degrees all the way down, which is the genuine strength of scaling channels this way.

What to do with a ramp like this

The ramp is a starting point, not a finished palette, and treating it as one is the actual mistake. Three practical moves:

• Judge the steps by measurement, not by the mix percentage. Take the contrast ratio between adjacent steps rather than trusting that "20 percent apart" means anything visually.
• Expect to hand-edit the dark half. Because the early dark steps are so large, the two or three darkest entries are often closer to each other than they look on a white page, and closer to black than you wanted.
• Pick ramp entries by the job. A border and a body-text colour need particular contrast against particular backgrounds. Choosing them by measured ratio beats choosing "step 3" because it is third.

One honest note on the tool: it works entirely in sRGB channel arithmetic. It does not use HSL, Lab or OKLCH, and it does not attempt to equalise perceived lightness. That keeps the output exactly reproducible and the hue stable, and it means the unevenness above is a property of the method rather than a bug in it. If you need a ramp that steps evenly in perceived lightness, you need a colour space built for it — and you will trade some hue stability to get there.