Most business websites do not need a dark mode, but a growing share of visitors have their device set to a dark theme, and a site that ignores that setting can feel harsh to them. The sensible question is not “dark or light?” but “can we support the visitor’s preference without doubling our design and testing workload?” For a small site with a tight colour system, the answer is often yes. For a busy site with heavy photography and many third-party widgets, it may be better to ship one excellent light theme.
What dark mode actually is on the web
Browsers expose the visitor’s operating system setting through a CSS media query called prefers-color-scheme. Your stylesheet can read it and swap colours. According to web.dev’s guide to prefers-color-scheme, the query reports whether the user prefers a light or dark theme, and it is supported in current versions of Chrome, Edge, Firefox and Safari.
A second piece is the color-scheme property. Declaring color-scheme: light dark tells the browser that your site supports both themes, so it can adapt built-in interface elements such as form fields and scrollbars to match.
There are therefore three possible levels of support:
| Level | What it means | Effort | Risk |
|---|---|---|---|
| Light only | One theme, dark-mode visitors see the light site | Lowest | Glare for some visitors, nothing else |
| Follow the system | Site switches automatically via CSS | Moderate | Two themes to test everywhere |
| Follow the system plus a toggle | Visitors can override the system choice | Highest | Saved preference, more states to test |
When it is worth doing
Dark mode earns its place when:
- Visitors read for long stretches, for example documentation, articles or dashboards.
- Your audience skews towards evening or low-light use, such as entertainment, gaming or developer tools.
- Your design already runs on a small set of colour variables, so a second set is a modest addition.
- You build a web app or portal where people stay logged in for long sessions.
It is harder to justify when your brand depends on one precise colour treatment, when most pages are image-led product shots on white, or when you do not have the capacity to test both themes after every change.
Design considerations
Do not simply invert colours
A dark theme is a separate design, not a filter. Pure white text on pure black tends to feel glaring. The web.dev guide recommends avoiding pure white on dark backgrounds and using a slightly dimmer off-white to reduce glare. Brand colours often need adjusting too: a saturated accent that looks confident on white can vibrate on a dark background.
If your brand colour palette was chosen with only a white page in mind, plan time to define dark-theme equivalents and record them in your brand guidelines.
Name colours by role, not by hue
The same guide advises semantic variable names such as --accent-color rather than --highlight-yellow, because a “yellow” may not look yellow in dark mode. In practice, define roles (background, surface, text, muted text, accent, border) once, then assign different values per theme.
Handle images and icons deliberately
Photographs can look too bright against a dark page. web.dev suggests slightly desaturating or darkening photos in dark mode with a CSS filter. Inline SVG icons that use currentColor inherit text colour automatically, while logos supplied as images may need a separate light-on-dark version. Check your logo files include one that works on dark backgrounds.
Accessibility: contrast still rules
Dark mode is not automatically more accessible. Under WCAG 2.2 success criterion 1.4.3, normal text needs a contrast ratio of at least 4.5:1 and large text at least 3:1, as set out in the W3C’s Understanding Contrast (Minimum). Those thresholds apply in both themes. Common dark-mode failures are grey secondary text that is too dim, borders that vanish, and placeholder text in form fields.
A practical checklist:
- Check every text and background pair in both themes, not just the main body text.
- Test focus outlines, links and buttons in their hover and disabled states.
- Look at charts, maps and embedded content, which often ignore your theme.
- Review cookie notices and chat widgets, which may be light-only.
Implementation notes
The core approach from web.dev is straightforward: keep a base stylesheet, define colours as CSS variables, and override those variables inside a prefers-color-scheme: dark block. Follow the system setting by default and, if you add a toggle, remember the visitor’s choice. Test using your browser developer tools, which can emulate the media feature.
Two cautions for polish. First, a wrong-theme flash on load looks cheap, so resolve the theme before the page paints. Second, every new component you add later needs both themes, so build that check into your design review. If your site runs many third-party scripts, see our guide to JavaScript weight and third-party scripts, since those widgets are the usual source of theme mismatches.
A simple decision framework
- Do analytics or customer feedback suggest visitors browse at night or in low light? If yes, lean towards supporting it.
- Is the colour system already variable-driven? If yes, the cost is low.
- Can you test both themes on every release? If no, wait.
- Does the brand have approved dark-background versions of its logo and palette? If no, create those first.
If most answers are no, a polished single theme with solid contrast is a better use of budget than a rushed second one.
Where Radiance Impact fits
Radiance Impact’s Technology division builds business websites and redesigns, and can include a dark theme where it suits the audience and the brand. If you are weighing it up for your own site, get in touch or read more about our website services.
