The inversion problem

The quickest dark mode is a CSS filter: invert(1). It takes thirty seconds and produces something almost unusable — photo colours flip to their complementaries, shadow glows, white text on black reads at a contrast ratio that triggers accessibility warnings in the opposite direction. Nobody ships that, but plenty of teams do something functionally equivalent: they swap a light token set for its arithmetic complement and call it done. The result is subtler but broken in the same way.

The core mistake is treating dark mode as a transformation of the light theme rather than a sibling of it. A light theme is built on a white or near-white ground with greys descending toward black; surfaces are differentiated by being lighter or darker than the page. On a dark ground the same logic inverts, but the perceptual results do not map cleanly. Human vision is adapted to lit environments. We are less sensitive to contrast gradations among dark tones than among light ones, so the subtle steps that separate a card from a sidebar in the light theme become invisible in the dark. The hierarchy collapses.

A monitor's glow lighting a dark wall
The screen is out of frame. What the wall shows is the colour temperature it was left on.

Shadows compound the problem in an instructive way. A drop shadow is a darker region below a surface — it reads because dark is below bright. On a dark ground, a shadow of the same hue and opacity is almost undetectable. Elevation, which shadows exist to signal, disappears. Some interfaces respond by brightening higher surfaces rather than dropping shadows beneath them: a card sits on a base of, say, 12% lightness while the card itself sits at 16%. The hierarchy is in the surfaces, not beneath them. This is not a workaround; it is a different depth vocabulary, and it requires deliberate construction.

Grey is not one thing

Greys in a dark theme carry more perceptual weight than they do in the light, because they are doing more structural work against a dark field. The commonly inherited grey ramp — generated by stepping linearly through HSL lightness — rarely survives this scrutiny. Linear steps in HSL do not produce perceptually uniform steps, and a ramp tuned for light backgrounds will have the wrong spacing when inverted.

The practical consequence: a dark palette needs its own grey sequence, authored from scratch or at minimum adjusted by eye against the dark ground. The steps between 10% and 30% lightness need to be wider and more deliberate than the equivalent range in the light theme. What reads as a tasteful whisper of differentiation at the light end of a palette becomes invisible mud at the dark end.

Accent colours require the same discipline. A vivid accent — say, a saturated orange used on interactive elements — is calibrated against a white ground. Drop that same value onto a very dark grey and it can tip into neon aggression, losing all of its designed character. The fix is not to desaturate it uniformly; desaturating an accent in the dark theme often makes it look sick rather than refined. The better approach is to adjust lightness and saturation together, treating the dark accent as a separate stop on the colour scale. Many design token systems now encode this explicitly: a single semantic token (color.action.default) resolves to different raw values in each theme, not because someone was being fussy, but because the colour on screen genuinely needs to be a different colour.

A hard-edged shadow cast across a plain coloured card
One hard edge does the work a blur radius is usually asked to do, at none of the cost.Photo: Andrzej Gdula / Pexels

Writing the second palette

The implication for teams is unglamorous but clear: two design decisions, not one, for every colour and every surface. This doubles certain parts of the palette audit. It also means the dark theme benefits from being designed in context — not previewed by toggling a class on a finished light comp, but built alongside it, with the dark ground open in a separate artboard from the beginning.

The token infrastructure to support per-theme values has existed in most major design systems for several years.

The difficulty is not technical. The token infrastructure to support per-theme values has existed in most major design systems for several years. The difficulty is attention: the dark theme tends to be treated as a derivative, a phase-two item, something that will be revisited. The visual gaps that result — the glowing shadows, the muddy midtones, the accents that lost their character in transit — are the direct cost of that deferral. Pure black is a trap on OLED and for legibility; the subtler trap is assuming the theme between black and white designs itself.