How to Design Colors for Dark Mode

Dark mode is not simple inversion

Reversing every light value usually produces excessive glare, weak depth, and distorted brand colors.

Use a near-black base and one or more elevated surfaces. Maintain visible separation through lightness, borders, or shadows that are designed for dark backgrounds.

Preserve semantic role names so components switch values without changing meaning.

Create surface hierarchy

Layered surfaces help users understand elevation and grouping.

A dark page background can be slightly darker than cards, menus, and dialogs. Borders should remain visible without becoming bright outlines around every component.

Test the surfaces on common displays because very small dark differences can disappear with low-quality panels, brightness settings, or ambient light.

Control text brightness and glare

Pure white on pure black provides maximum numerical contrast but can feel harsh for long reading.

Use a softened near-white for body text while retaining enough contrast. Secondary text can be dimmer, but avoid pushing it below the intended contrast target.

Do not reduce opacity indiscriminately because compositing changes the effective color across different surfaces.

Adapt accent colors

A vivid accent designed for white backgrounds can appear overly bright on a dark surface.

Create theme-specific action and status values. Often the dark-mode variant is lighter but slightly lower in chroma so it remains visible without blooming.

Check on-accent text separately. A lighter accent may require dark text even if the light-mode button used white text.

Interaction states and focus

Dark mode needs explicit hover, active, selected, disabled, and focus values.

Ensure each state changes through more than a subtle hue shift. Focus indicators must contrast with the component and its surrounding surface.

Pay special attention to destructive actions, warning banners, data visualizations, and disabled controls because low-light designs can make state differences collapse.

Implement with semantic tokens

Theme mappings keep component code stable.

:root {
  --surface-page: #F8FAFC;
  --surface-card: #FFFFFF;
  --text-primary: #0F172A;
}

[data-theme="dark"] {
  --surface-page: #0B1020;
  --surface-card: #151C2F;
  --text-primary: #E8EDF7;
}

Dark-mode testing workflow

Evaluate dark mode as its own interface.

1. 1

   Review surface layers and component boundaries.

2. 2

   Check normal text, muted text, and on-action text.

3. 3

   Test accent and status colors for glare and separation.

4. 4

   Inspect hover, active, selected, focus, and disabled states.

5. 5

   Run grayscale and color-vision simulations.

6. 6

   Test at low and high screen brightness.

7. 7

   Verify system theme switching and saved preference behavior.

Common dark-mode mistakes

Dark palettes fail when the design removes hierarchy or relies on opacity.

• Using pure black for every surface
• Using pure white for all text
• Reusing light-mode accent values unchanged
• Making secondary text too faint
• Using transparent borders without checking compositing
• Forgetting focus and selected states
• Treating dark mode as a filter rather than a theme

Key takeaways

Dark mode should preserve hierarchy, readability, and semantic meaning.

• Use layered near-black surfaces.
• Soften text while preserving contrast.
• Create dark-specific accent variants.
• Map values through semantic tokens.
• Test all states independently.
• Respect user theme and reduced-motion preferences.

Frequently asked questions

Primary references

These sources support the standards and technical explanations in this guide. Color Pick recommendations and product-specific limitations are identified separately in the article.

1. Understanding Success Criterion 1.4.3: Contrast (Minimum)W3C Web Accessibility Initiative
2. Understanding Success Criterion 1.4.11: Non-text ContrastW3C Web Accessibility Initiative
3. CSS Color Module Level 4W3C
4. Media Queries Level 5 — prefers-reduced-motionW3C