Dark Mode Isn't a Toggle. It's a Second Design.

The reason most dark modes feel off is straightforward: they were built by flipping a switch. Someone inverted the palette, checked that white became black, called it done. The mode exists. It technically functions. Users can enable it. But every interaction feels slightly wrong, text strains the eyes after ten minutes, and borders disappear into backgrounds because no one recalculated the contrast ratios for the new context.

Dark mode design is not a setting you toggle in your style sheet. It is a parallel design system that shares your brand but makes different decisions at every level. The reason this matters is that human vision behaves differently against dark backgrounds. What worked in light mode will not simply invert and work again. You need to rebuild the hierarchy, rethink the emphasis, recalculate the spacing that guides the eye. This article walks through what actually changes when you do it properly, and the process we follow before we ship it.

Why contrast ratios break when you invert

Contrast in light mode is calculated against white or near-white backgrounds. A medium grey that hits WCAG AA at 4.5:1 against white will fail catastrophically when you flip it to sit on black. The math does not reverse symmetrically. Lighter greys that provided subtle differentiation in light mode now blast at full brightness in dark mode, while your carefully chosen mid-tones vanish entirely.

This is why we recalculate every single text colour, border and background pair from scratch. We do not invert values. We test each combination against the new background using the same WCAG contrast guidelines, then adjust until the ratio lands where it needs to be. For body text, that means 4.5:1 minimum. For large text and UI components, 3:1. The colours that meet those thresholds in dark mode are almost never the mathematical inverse of your light mode palette.

We also reduce pure white. Bright white text on pure black creates harsh halation, a glow effect that makes letters blur at the edges. We step the text down to a warm off-white around #E4E4E4 or #F0F0F0, and lift the background to a dark charcoal rather than true black. The result is a softer contrast that maintains readability without the eye strain.

Shadows stop working and need replacing

Shadows in light mode create depth by adding darkness beneath an element. In dark mode, there is no darker to go. Dropping a black shadow onto a dark background produces nothing visible. The entire layer system flattens, cards lose their elevation, and the interface feels like a single plane of elements stuck to the screen.

The fix is to invert the logic. Instead of shadows, we add light. We draw a subtle bright outline or a soft glow in a lighter tone to lift elements off the background. Sometimes we increase the background colour of the raised element itself, making it a shade or two lighter than the base layer. The principle stays the same: communicate hierarchy through contrast. The method reverses.

This also applies to borders. Thin borders that separated sections in light mode often disappear in dark mode because the contrast is too low. We increase their opacity or shift them to a lighter tone so the structure remains visible. Every line that defines a boundary needs individual attention.

Component states require separate definitions

Hover states, focus indicators, disabled buttons and active tabs all rely on colour shifts to signal their status. In light mode, you might darken a button on hover. In dark mode, darkening it makes it disappear. You need to lighten it instead, or add a border, or change the approach entirely.

We define each interactive state twice: once for light mode, once for dark mode. A focus ring that uses a blue outline in light mode might need a brighter blue or a double-stroke treatment in dark mode to remain visible. Disabled states that grey out in light mode might need to reduce opacity and add a subtle border in dark mode so they remain distinguishable from the background.

The same applies to form fields. Placeholder text, error messages, validation icons all need their own dark mode values. We test every possible state in both modes during website design reviews, because overlooking a single interaction state is how you end up with invisible error messages or buttons that look disabled when they are active.

Testing across actual devices and lighting conditions

We do not trust emulators alone. Dark mode performs differently on OLED screens versus LCD panels, and what looks balanced on a desktop monitor can feel blown out on a phone in a dark room. We test on physical devices, in multiple lighting conditions, with the brightness turned down to realistic nighttime levels.

We also check for colour bleed. Some colour combinations that look fine in light mode produce visual artefacts in dark mode, especially around high-contrast edges. Reds and blues can vibrate against dark backgrounds. Saturated colours often need desaturating to prevent them from overwhelming the interface.

Motion and transitions need gentler treatment

Animations and transitions that feel smooth in light mode can appear jarring in dark mode. Bright elements moving across a dark background create stronger afterimages. Users notice stutters and frame drops more readily because the contrast makes every movement more pronounced.

We reduce animation speeds slightly in dark mode, and we dial back the brightness of any glowing or pulsing effects. Loaders and progress indicators often need their colours softened. The goal is to maintain the same sense of responsiveness without the visual fatigue that comes from watching bright objects dart around a dark field.

What we check before we ship

Our dark mode checklist covers more than colours. We verify that every text colour meets contrast requirements against its specific background. We check that all interactive states remain visible and distinguishable. We review shadow and border treatments to ensure hierarchy is clear. We test SEO elements like structured data and meta tags to confirm they reference the correct assets in both modes.

We also validate that mode preference persists across sessions, that the toggle is accessible via keyboard, and that switching modes does not cause layout shifts or flashing. If your app development includes user-generated content, we test how user-uploaded images and videos render in both modes, because media that looks fine on white can become illegible on black.

We run automated accessibility audits using tools that flag contrast failures, but we pair those with manual testing. Automated tools catch mathematical failures. Human testers catch the things that pass the math but still feel wrong: text that vibrates, icons that lose meaning, CTAs that blend into their surroundings.

The decision log that keeps both modes aligned

We maintain a shared decision log that documents every choice made for both modes. When we adjust a colour in light mode, we note whether the equivalent dark mode colour needs changing. When we introduce a new component, we define its appearance in both contexts before we build it. This log prevents drift, where one mode gets updated and the other is forgotten.

The log also records why we made each choice. It explains which colours failed contrast tests, which shadows were replaced with glows, which animations were slowed. Future updates reference this document so new team members understand the reasoning and do not undo decisions that solved specific problems.

This approach applies across services we provide. Whether we are building a new site, extending an existing platform, or refining content writing templates, the principle holds: dark mode is not an afterthought. It is a parallel system that deserves the same rigour as your primary design.

When we hand over a project, both modes are documented, both are tested, and both are ready to evolve without breaking. That is what separates a design that works in the dark from one that was just inverted and shipped. If you are planning to add dark mode to your site or app, the time to plan it properly is now. Get in touch and we will walk you through what it takes to build both modes right from the start.