Skip to content
ColorArchive
Dark Mode Design
Search intent: dark mode color design adaptive color system light dark mode design tokens semantic color variables dark mode palette guide

Adaptive Color Systems: Building Palettes for Light and Dark Mode

Building a color system that works in both light and dark modes requires semantic token architecture, surface layer design, and independent accessibility checking for each mode — not palette inversion.

Dark ModeDesign SystemsDigital Design
Key points
A palette designed for light mode does not invert to dark mode — contrast relationships, saturation, and surface layering all require independent design decisions for each mode.
Semantic tokens (surface-primary, text-default) are the architectural foundation of adaptive systems — they define roles that hold the same structural meaning across both modes.
Brand colors rarely translate directly between modes without adjustment; full-saturation brand colors often read as harsh on dark backgrounds and need a lighter, slightly desaturated dark-mode variant.

Why inversion fails

The naive approach to dark mode — inverting the light palette — fails because color perception is not symmetric. Colors that are muted and restrained on a white background appear vivid and aggressive on a dark background. Contrast relationships that work in light mode may be insufficient or excessive in dark mode. The elevated surface stack works through adding gray in light mode and adding white in dark mode — the same operation in opposite directions. An effective adaptive color system must be designed for both contexts independently, with a shared token architecture that allows controlled variation rather than automatic inversion.

Semantic tokens as the foundation

The structural foundation of an adaptive color system is the semantic token layer. Semantic tokens define color roles — surface-primary, text-default, border-subtle, action-primary — without encoding specific color values. The values assigned to these roles change per mode, while the component code that consumes the tokens remains unchanged. This architecture means a dark mode implementation requires only new token value assignments, not component rewrites. Every adaptive color system should start with a complete semantic token inventory before assigning any specific color values.

Surface elevation in dark mode

The surface elevation system — how background, cards, modals, and overlays are differentiated — works differently in dark mode. In light mode, elevated surfaces are lighter than the base background (adding gray to white). In dark mode, elevated surfaces are lighter than the dark base (adding white to dark). Material Design popularized this convention with its 'overlay' model: each elevation level applies a white overlay at increasing opacity over the base dark color. The practical effect is that in both modes, elevated surfaces appear lighter than their parent surface, consistent with real-world lighting conventions.

Accessibility in adaptive systems

Accessibility evaluation must be performed independently for both modes. A text-on-background combination that passes WCAG 4.5:1 in light mode may fail in dark mode if the dark-mode token values were chosen by visual judgment rather than computed contrast. The practical requirement is automated contrast checking against both token sets as part of the build or design review process. Any failure in either mode should be treated as a blocking issue. Some teams run contrast checks as part of CI — any token change that introduces a contrast failure blocks the pull request.

Practical next step

Move from the guide into a concrete palette lane

Guides explain the use case. Collections prove the taste. Packs handle the export and implementation layer.

Related guides