Should Your Product Support Dark Mode?
By CodexierPublished 5 min read
Dark mode requests arrive sooner or later in every digital product. Sometimes they come from users who spend hours a day in the tool, sometimes from a founder who likes the look. The answer depends on who your users are and how your interface is built. With colour defined as tokens, dark mode is a contained piece of work; with colours hard-coded across hundreds of components, it becomes a redesign. This guide helps you decide and, if you do it, do it properly.
Who expects dark mode
On mobile, both iOS and Android have had system-wide dark mode for years, and many people leave it on permanently. A native app that ignores the setting stands out as a bright rectangle at night, which users notice. On the web the expectation is weaker: most visitors to a company website will not miss dark mode, while users of a web app they work in all day often will.
| Product type | Expectation | Recommendation |
|---|---|---|
| Native mobile app | High; the system setting is widely used | Support it, following the system setting |
| Web app used for hours daily | Medium to high | Support it if colours are tokenised |
| Marketing website | Low | Usually skip; spend the effort on content and speed |
| Checkout, booking and forms | Low | Skip unless the surrounding product has it |
What it costs to design and test
Dark mode is not inverting colours. Surfaces need elevation expressed through lighter shades rather than shadows, brand colours often need a lighter variant to stay readable on dark backgrounds, and pure black with pure white text causes glare for many readers. Each state, from hover and focus to errors, disabled and selected, needs checking in both themes, and each must meet the contrast requirements of WCAG. The design work is roughly one more palette plus a review of every component; the test work is every screen twice.
- A second set of values for every colour role: backgrounds, surfaces, text, borders, brand, status colours.
- Contrast checks for text and interactive elements in both themes.
- Visual review of every component and every screen, including empty and error states.
- Handling of third-party content: embedded maps, payment widgets and email templates.
Tokens that make it cheap
The difference between a cheap and an expensive dark mode is whether components refer to colours by role or by value. If a button uses a token called something like colour-action-primary, dark mode is a matter of giving that token a different value in the dark theme. If a button uses a hex code directly, every component must be edited. A design system with semantic tokens is what makes dark mode, and later brand changes, a configuration job rather than a rebuild. Our guide on whether your company needs a design system covers the wider trade-off.
Primitive tokens
The raw palette: every shade of your brand colour and greys, named by value. Components never use these directly.
Semantic tokens
Roles such as surface, text-muted, border, action and danger, mapped to primitives separately for light and dark.
Component use
Components refer only to semantic tokens, so switching theme changes the mapping and nothing else.
Images, logos and charts
Content is where dark mode usually breaks. Logos with dark text disappear on dark backgrounds and need a light variant. Screenshots and illustrations with white backgrounds glare, so give them a subtle frame or a dark version. Chart colours chosen for white backgrounds may lose contrast; define chart palettes as tokens too and check them in both themes. Brand colours that pass on white can fail on dark, as explained in our guide to brand colours that pass contrast.
Shipping it well or not at all
A half-done dark mode is worse than none: unreadable error messages, invisible borders on inputs and a white flash on page load damage trust. If you do it, follow the system preference, store the user's override, apply the theme before the first paint to avoid the flash, and include both themes in every design review and release test from then on.
When not to buy this from us: if your product is a marketing site or a short transactional flow, dark mode is rarely worth the ongoing test cost, and we will say so. If you are building or cleaning up a design system anyway, adding dark mode at the same time is the cheapest moment. Our design system and UI kit includes semantic tokens ready for theming; see pricing or book a call.
Frequently asked questions
Does dark mode save battery?
On phones with OLED screens, dark pixels use less power, so a genuinely dark interface can reduce consumption. On LCD screens there is little difference. It is a nice side effect, not a strong reason by itself.
Is dark mode better for accessibility?
It helps some users, such as people sensitive to glare, and is harder for others, such as some people with astigmatism who find light text on dark backgrounds blurrier. That is why the choice should be the user's, with the system setting as default.
Should we use pure black backgrounds?
Usually not. Very dark grey reduces glare and lets you show elevation with slightly lighter surfaces. Pure black can make sense on OLED-focused mobile apps, but test readability carefully.
Can we add dark mode later?
Yes, and the cost depends on whether components use semantic tokens. If they do, it is mostly design and testing. If not, the first step is refactoring colours into tokens, which is worth doing anyway.
Find out what dark mode would cost in your product
Show us your product and how colours are defined today. In fifteen minutes we can tell you whether dark mode is a configuration job or a bigger clean-up, and whether it is worth it.
Book a free 15-minute call