Dark mode has become an expected feature in almost every operating system and in many apps. Users choose it for different reasons: comfort in dim light, aesthetic preference, sensitivity to light, or to reduce power use on OLED screens, where black pixels are switched off. But a dark mode made in a hurry, by simply inverting the colours, creates more problems than it solves.
It is not a colour inversion
The most common mistake is taking the light theme and swapping white for black. The result usually has excessive contrast, accent colours that become irritating, shadows that can no longer be seen and images that clash.
Designing a dark mode means rethinking a few things:
- the background: a very dark grey is often more comfortable than pure black, because it softens the extreme contrast with the text and leaves room to distinguish layers;
- the text: a slightly muted white is less tiring than full white on full black;
- accent colours: very saturated hues that work on a light background tend to «vibrate» on a dark one; lighter, less saturated versions work better;
- depth: in a light theme layers are separated by shadows, in a dark theme shadows are hard to see, so it helps to lighten foreground surfaces slightly.
Pure black still has its place, for example in apps designed for OLED screens or in video players. It is not forbidden: it is a choice to make deliberately.
Contrast still matters in the dark
WCAG contrast requirements do not change with the theme: at least 4.5:1 for normal text and 3:1 for large text and for interface components such as field borders and meaningful icons, at level AA. They must be checked separately for both themes, because a colour that meets the threshold on white may not meet it on dark grey.
A typical problem concerns status colours. A dark red for errors, perfectly readable on white, can become almost invisible on a dark background. Every semantic colour, such as error, warning, success and link, needs its own dark theme variant.
A layered palette
A tidy way to build dark mode is to define a few surface levels, each slightly lighter than the one before:
| Level | Use | Example colour |
|---|---|---|
| Background | Main page area | #121212 |
| Surface 1 | Cards, panels | #1e1e1e |
| Surface 2 | Menus, overlays | #2a2a2a |
| Primary text | Body text | #e6e6e6 |
| Secondary text | Captions, notes | #a8a8a8 |
The values are indicative: they should be adapted to the product's visual identity and checked with a contrast tool.
Respecting the user's choice
On the web, the prefers-color-scheme media query lets you read the preference set in the operating system. The most maintainable approach is to define colours as CSS variables and change their values:
:root {
--background: #ffffff;
--text: #1f1f1f;
--accent: #0b57d0;
}
@media (prefers-color-scheme: dark) {
:root {
--background: #121212;
--text: #e6e6e6;
--accent: #8ab4f8;
}
}
body {
background: var(--background);
color: var(--text);
}
As well as following the system, many users appreciate a switch in the interface with three options: light, dark, automatic. The choice should be remembered between visits. It is also worth telling the browser which themes are supported with the color-scheme property, so that scrollbars and native form controls adapt too.
Images, logos and charts
- Logos: a dark logo on a transparent background disappears in the dark theme; you need a light version or a backing.
- Photos: usually left unchanged; some interfaces lower their brightness slightly so they do not dazzle.
- Illustrations and icons: SVG ones can use
currentColoror CSS variables to adapt automatically. - Charts: data palettes need reviewing, because colours designed for a white background can blur together on a dark one.
- Screenshots and images with a white background: on a dark page they create a flash of light; a border or slightly rounded corners soften the effect.
Who prefers what
There is no single best theme. Some people with certain visual conditions read better on a dark background, while others find that light text on a dark background seems to «bleed», an effect familiar in particular to people with astigmatism. That is exactly why the choice must stay with the user, and why neither theme should be a second-class version.
How to check
- Switch between the light and dark themes on every type of page, not just the home page.
- Check the contrast of text, links, status colours and field borders in both themes.
- Look for elements left with fixed colours, such as black icons, embedded white backgrounds, generated emails and documents.
- Test in different lighting: a dark room and daylight.
In short
- Dark mode must be designed, not produced by inverting colours.
- Very dark greys and slightly muted text are often more comfortable than extreme contrast.
- WCAG contrast requirements apply to both themes and must be checked separately.
- CSS variables and
prefers-color-schememake the theme easy to maintain; a manual switch completes the experience. - Logos, charts and images with white backgrounds need specific attention.
