Skip to content
InsideUX Design
Design 18 min read

Designing Dark Mode Right: Colors, Contrast and Common Mistakes

A good dark mode is more than inverted colors. What research says about readability and how to design surfaces, accent colors, contrast and images for dark interfaces.

Picture the app of a city magazine: long features, an events calendar, lots of photos, partner logos and tickets with QR codes. The team has built a dark mode, and built it fast. The background is pure black, the text pure white. Links and category tags glow in the brand’s bright red. The calendar cards have shadows nobody can see anymore. Partner logos sit in white boxes, and photos blaze like floodlights. And because dark mode is popular right now, the app launches in dark mode for everyone.

The first feedback is mixed. Some people love the new look. Others complain that the text starts to shimmer after a few paragraphs, that red links are hard to read and that the scanner at the venue entrance cannot read the QR code. A few simply ask how to get the light version back.

A good dark mode is more than inverted colors. It needs its own decisions about surfaces, depth, accent colors, contrast and images, and it has to respect what people have set on their devices. This article covers what research says about readability, how to design a dark mode and which mistakes come up again and again. The city magazine app serves as a running example throughout. It is made up, but typical.

Why people use dark mode

A small 2023 survey by the Nielsen Norman Group (NN/g) gives a sense of how common dark mode is. Of 115 people asked about the setting on their phone, roughly a third used dark mode, a third light mode and a third a mix of both. The sample is small, but the picture is clear: dark mode is not a niche topic.

The reasons respondents gave were mainly these:

  • Less eye strain: This was the most common reason among people with normal vision.
  • Saving battery: This only works on OLED screens, and according to NN/g, screen brightness matters at least as much as the mode.
  • Aesthetics: Many people simply find dark interfaces more attractive.
  • Accessibility: Some people with visual impairments, such as cataracts, find dark interfaces easier to use.

The battery argument deserves a closer look. In 2021, a team led by Charlie Hu at Purdue University measured it on four OLED phones and presented the results at the MobiSys conference. At full brightness, switching from light to dark mode saved an average of 39 to 47 percent battery power, according to the university. At 30 to 50 percent brightness, which is typical in everyday use, the savings dropped to just 3 to 9 percent. That is so little, the university noted, that most people would not notice the slightly longer battery life.

The same NN/g study made an observation that matters a lot for design: people expect dark mode to be a system-wide setting that all apps and websites follow. Once they turn it on in their operating system, they do not want to hunt for it in every single app.

What research says about readability

Researchers call dark text on a light background positive polarity and light text on a dark background negative polarity. Which one is easier to read has been studied many times. For people with normal or corrected vision, the answer is fairly clear.

In 2013, a team led by psychologist Cosima Piepenbrock at the University of Düsseldorf had younger and older adults complete a visual acuity test and a proofreading task in both polarities. According to NN/g’s summary, the younger group was 18 to 33 years old and the older group 60 to 85. Both groups performed better with dark text on a light background, and the researchers recommend positive polarity for all age groups.

A second study by the same team, published in 2014, used four font sizes from 8 to 14 points. The advantage of positive polarity grew as the text got smaller. The usual explanation lies in the optics of the eye: a bright screen makes the pupil contract, which produces a sharper image with fewer optical aberrations, much like a camera with a smaller aperture.

A dark environment does not automatically give light text the edge either. In 2017, Dobres, Chahine and Reimer tested how well people read words in brief glances, like a quick look at a car display. In near-darkness, white text on black performed worst. In daylight conditions, all variants improved markedly.

That is not the whole picture, though:

  • Visual impairments: NN/g points to a 1985 study by Legge and colleagues with low-vision readers. All seven participants with cloudy ocular media, for example from cataracts, read faster with light text on a dark background. One caveat: the study used CRT monitors, which flicker more in light mode.
  • Long-term effects: In 2018, a team around Frank Schaeffel at the University Hospital Tübingen found in seven participants that reading black text on white for an hour made the choroid, a layer of the eye, about 16 micrometers thinner. With white text on black, it became about 10 micrometers thicker. A thinner choroid is associated with the development of myopia. That is an interesting hint, but not proof that dark mode prevents nearsightedness. The researchers themselves stress that the approach still needs to be verified.
  • Perception versus performance: What people feel and what they actually achieve do not always match. In the font size study, according to NN/g, participants reported no difference in perceived readability, even though their performance differed.

NN/g draws a clear conclusion: do not make dark mode the default for everyone, but let people choose. Applications built for long-form reading, such as news, magazines or e-books, should offer it in particular. For the city magazine app, this means two things. Dark mode stays, but it is no longer the default for everyone. And because font size matters so much, the body text of the features gets a generous size in both modes.

No pure black, no pure white

The most obvious dark mode is white on black. At 21:1, it delivers the highest possible contrast ratio, so it sounds like the best option. Material Design, Google’s design system, recommends something different nonetheless.

Material typically uses a dark gray with the value #121212 for the bottom layer of a dark interface. The Material Components documentation explains that the gray keeps shadows more visible and makes light text less tiring for the eyes. Something similar applies to the text itself: a Google codelab notes that pure white text on a dark background can appear to bleed or blur. Material therefore uses white text at reduced opacity: 87 percent for high-emphasis text, 60 percent for medium emphasis and 38 percent for disabled elements.

Note that this is not a decision against contrast. Light gray text around #E0E0E0 on #121212 still reaches about 14:1, more than three times the WCAG minimum for body text. Even a mid gray like #A0A0A0 comes in at just over 7:1, comfortably on the safe side.

  • Before: Background #000000, body text #FFFFFF, captions in a gray nobody has checked.
  • After: Background #121212, body text #E0E0E0, captions and metadata #A0A0A0. Body text uses a regular weight instead of the thin cut that looked fine in light mode.

That last point also shows up in NN/g’s research: fonts that are too thin are among the typical problems in dark mode. Fine strokes that look elegant on white quickly lose legibility on a dark background.

Depth through lighter surfaces, not shadows

In light interfaces, shadows show what sits on top of what: a card above the background, a dialog above the page. On a dark background, that barely works. The Material Components documentation states that shadows are less effective in a dark theme because they have less contrast. NN/g also lists disappearing shadows and overlays as a typical issue.

The solution is to express depth through lightness. The higher a surface sits, the lighter it gets. The second version of Material Design implemented this with semi-transparent white overlays that grow stronger with elevation. In the Google codelab, for example, a card gets a white overlay at 2 percent opacity and the bottom app bar one at 12 percent. Material 3 replaced this system with fixed, tone-based surface colors, ranging from surfaceContainerLowest to surfaceContainerHighest. The principle is the same, but the colors are now roles of their own.

Apple takes the same approach in its Human Interface Guidelines. In Dark Mode, there are two sets of background colors, called base and elevated. Base colors are dimmer and make background interfaces recede, while elevated colors are brighter and bring foreground interfaces forward.

  • Before: Calendar cards in black on black, separated only by a shadow nobody can see. A filter dialog appears over the list without any visible edge.
  • After: Page background #121212, cards one step lighter, the filter dialog one step lighter still. Where cards need a clear boundary, a subtle divider helps as well.

If people need the edge of a dialog or menu to recognize it as such, WCAG success criterion 1.4.11 applies, with at least 3:1 against adjacent colors. Two dark grays that sit close together rarely get there.

Desaturate accent colors

Brand colors are usually chosen for light interfaces. On a dark background, they behave differently. The Google codelab explains that highly saturated colors tend to visually “vibrate” against dark backgrounds, which makes them harder to read. NN/g also lists saturated colors on dark backgrounds as a common mistake.

On top of that, there is a hard contrast problem. The city magazine’s red, #D0021B, reaches a contrast ratio of about 5.7:1 on white, which makes it fine as a link color in light mode. On #121212, it only reaches about 3.3:1. For regular body text, that falls short of WCAG.

The fix is a lighter, less saturated version of the same color for dark mode:

  • Before: Links, category tags and buttons in brand red #D0021B, garish on black and too low in contrast for small text.
  • After: In dark mode, a light coral red such as #F28B82. It reaches about 7.8:1 on the background and still just under 5.9:1 on the lighter cards. The brand remains recognizable without the shimmer.

To avoid deciding this case by case, such colors belong in semantic tokens: named color roles like “link color” or “elevated surface” that point to a different value depending on the mode. Apple explicitly recommends using semantic colors that adapt to the current appearance and avoiding hard-coded color values. The article Design Systems for Small Teams shows what such a system can look like for a small team.

Colors that carry meaning need extra attention: an error red has to remain recognizable in both modes and should never be the only cue. The article Color Blindness in UX Design covers this in more detail.

Check contrast in both modes

The WCAG apply to dark mode just as they do to light mode. Success criterion 1.4.3 at Level AA requires a contrast ratio of at least 4.5:1 for text. For large text, meaning at least 18 point or 14 point bold, 3:1 is enough. Text that is part of a logo is exempt. Criterion 1.4.11 adds a requirement of 3:1 for interface components, their states and important graphics. Apple’s guidelines go further and recommend striving for 7:1 for custom color combinations, especially with small text.

Three things matter most when checking dark mode:

  • Check every combination twice. A color that passes in light mode can fail in dark mode, as the brand red shows. This includes placeholder text, disabled buttons, focus outlines and error messages.
  • Check every layer. Text that passes on the page background also has to pass on elevated surfaces, and vice versa.
  • Passing does not mean easy to read. The WCAG formula does not care whether the lighter color is the text or the background. Polarity research shows that this does make a difference to readability. In dark mode, a passing contrast ratio is a floor, not a seal of quality.

Apple also recommends testing dark mode together with the Increase Contrast and Reduce Transparency settings, both separately and combined. This can reveal places where dark text on a dark background becomes harder to read.

Images, logos and graphics

Many dark mode problems do not come from colors the team defined, but from content that comes from elsewhere. NN/g names a few typical cases: graphics with opaque backgrounds that show up as white boxes, logos with too little contrast and inverted QR codes that some scanners cannot read.

For the city magazine app, this means:

  • Photos: Apple recommends slightly darkening images with white backgrounds in dark mode so the background does not glow. On the web, a CSS filter that only applies in dark mode, such as slightly reduced brightness or saturation, does the job.
  • Logos: Instead of PNG files with white boxes, logos come without a background, with a separate light version where needed. On the web, the <picture> element with <source media="(prefers-color-scheme: dark)"> picks the right file automatically. Apple also advises creating separate light and dark versions of icons and images where necessary.
  • QR codes: Ticket QR codes stay dark on light in both modes, with a light margin around them. Wherever a device rather than a person does the reading, inverting is a bad idea.
  • Charts: Graphics such as an attendance chart for events need their own dark mode colors, and they also have to reach 3:1 against their surroundings if their elements are needed to understand the content.

Implementation: follow the system and let people choose

On the web, three building blocks make a clean dark mode much easier.

The prefers-color-scheme media query detects whether someone has chosen a light or dark color scheme in their operating system or browser. With @media (prefers-color-scheme: dark), you can set your own colors in response. The cleanest way is through CSS custom properties that map to your semantic tokens.

The CSS property color-scheme tells the browser which color schemes a page supports. With color-scheme: light dark, the browser adapts form controls, scrollbars and the page canvas, among other things. MDN recommends also adding <meta name="color-scheme" content="light dark"> to the head of the page to prevent unwanted flashes while loading.

The CSS function light-dark() takes two colors or images and returns one or the other depending on the active color scheme, without a separate media query. It requires color-scheme: light dark and, according to MDN, has worked in the latest versions of all major browsers since May 2024. Older browsers still need a fallback.

That leaves the question of who decides. NN/g recommends mirroring the operating system setting by default. An in-app switch is fine, but people are unlikely to look for it in most apps. For apps on its platforms, Apple goes further and explicitly advises against an app-specific appearance setting: people would have to adjust more than one setting, and they might think the app is broken if it does not respond to their system-wide choice. On web.dev, Google’s Thomas Steiner describes a middle path for websites: follow the browser’s signal first, then optionally let people override it.

This adds up to a simple rule. The default is always the system setting. A switch of your own is an extra, useful mainly where people read a lot or want a specific look just for your product. If you offer one, give it three options, “System,” “Light” and “Dark,” and remember the choice.

  • Before: The app launches in dark mode for everyone. The only way back to light mode is a hidden switch in the settings. Links to the ticket shop open a glaring white website.
  • After: The app follows the system setting. The reading settings for features offer “System,” “Light” and “Dark.” The embedded ticket shop adopts the color scheme.

NN/g explicitly calls out that last problem too: links from a dark app that open a light website. Consistency across all screens is one of the ground rules.

Testing dark mode

A dark mode is only finished once it has been tested in real situations.

In the browser: Chrome DevTools lets you emulate prefers-color-scheme through the Rendering panel without changing your system setting.

On real devices: Check dark mode at different brightness levels, in a dark room and in daylight, and also combined with increased contrast and larger text. Grays that are too dark or images that glare often only show up there.

With people: NN/g advises testing every design in dark mode as well, and not relying solely on design tool plugins. In a usability test, let participants work in the mode they normally use.

Email: Many email clients render messages in dark mode differently from how they were designed. NN/g recommends checking newsletters and system emails too.

Common mistakes

Simply inverting. Automatically flipped colors give you pure black and white, garish accents, invisible shadows and inverted photos. A dark mode needs its own, tested palette.

Dark as the default for everyone. This ignores both the readability research and the setting people have already chosen on their device.

Dark mode as a one-off project. If new components are only designed in light mode, you will have gaps within six months. Semantic tokens and a rule that every component is reviewed in both modes prevent that.

Forgetting states. Focus outlines, error messages, disabled elements and loading states are especially easy to overlook in dark mode. Yet they decide whether an interface stays usable. A focus outline that disappears in dark mode hits people who navigate with a keyboard hardest.

Treating dark mode as accessible by default. Dark mode is a real help for some people and a hindrance for others. Accessibility comes from choice and tested contrast in both modes, not from a particular mode. The article Why Accessibility Is More Than Contrast and Font Size explores this further.

Conclusion

Many people use dark mode, for comfort, out of preference or because it helps them see better. Research shows that dark text on a light background is easier to read for most people with normal vision, especially at small sizes. That is not an argument against dark mode. It is an argument for doing it well and letting people choose.

Doing it well means dark gray instead of black, softened white instead of pure white, depth through lighter surfaces, desaturated accent colors, contrast checked on every layer and images that do not glare. Technically, the interface follows the system setting, and a switch of your own is an addition.

After the redesign, the city magazine app does not have a spectacular new look. It has a dark mode that feels natural: it is there when someone has turned it on, it does not shimmer, the brand is recognizable and the QR code works at the entrance.

Checklist

  • The interface follows the system setting by default via prefers-color-scheme.
  • If there is a switch of your own, it offers “System,” “Light” and “Dark” and remembers the choice.
  • color-scheme is set so that form controls and scrollbars match.
  • The background is a dark gray rather than pure black, and the text a softened white.
  • Higher layers are lighter than lower ones instead of being separated only by shadows.
  • Accent and brand colors have their own desaturated versions for dark mode.
  • All colors exist as semantic tokens, not as hard-coded values.
  • Text reaches at least 4.5:1 in both modes and on every layer, large text at least 3:1.
  • Interface components, focus outlines and important graphics reach at least 3:1 in both modes.
  • Photos do not glare, logos have suitable versions and QR codes stay dark on light.
  • Linked pages, embedded content and emails have been checked in dark mode.
  • Dark mode has been tested on real devices, at different brightness levels and with accessibility settings.

Sources

Back to “All articles”

You might also like

Comic Sans: Why the World’s Most Hated Typeface Is Treated Unfairly

Design

Comic Sans is called the most hated typeface in the world, unfairly. Its story shows that the hate is really about how it was misused.

Forms Nobody Abandons: 12 Rules for Better Form UX

Design

Visible labels, well-timed validation, helpful error messages: 12 proven rules for forms, explained step by step using a real-world checkout example.

Design Systems for Small Teams: When They Pay Off and How to Start Small

Design

When a design system pays off for a small team and how to build one in twelve weeks: from a UI inventory and design tokens to your first ten components.