Dark theme is not just inverting colors

Short answer

Dark theme isn't achieved by inverting the light theme's colors; the background, surfaces, text, and accent colors are each rebuilt separately for a dark environment. A pure black background is usually avoided, because shadows don't show up against black, the depth between surfaces disappears, and the contrast between text and background becomes harsher than it needs to be; a dark gray leaves room for surfaces to lighten slightly as they rise in elevation. Saturated colors that work well in a light theme either become unreadable or appear to vibrate against a dark background; that's why dark theme picks a lighter, less saturated tone for the same role.

Why inverting isn't enough

The shortest way to move an interface into darkness is to invert every color: white becomes black, black becomes white, light blue turns into dark orange. This approach produces a result in a few seconds, and it produces the wrong result almost everywhere.

Inversion is a color operation, not a design decision. The brand blue turns into its complementary orange; it's no longer the brand blue. Photos turn into negatives, and human faces become unrecognizable. Shadows become a light halo, creating the impression that a card is sinking into the background rather than rising above it. Success green turns pink, error red turns cyan, and every state mapping built in UX-02 breaks.

The token structure from UX-01 pays off here. Components call on role names like "surface," "text on surface," "primary," or "error"; dark theme is these same names being bound to different steps in the raw palette. The designer's job is to choose the right value for each role in a dark environment, not to flip every color with a single switch.

Dark gray instead of pure black

The question on the lesson card looks at the first of these design decisions: why isn't a pure black background chosen for dark theme?

The answer starts with shadow. In a light theme, a soft shadow cast underneath a card tells you it's separated from the background. A shadow is an area darker than the background. If the background is already pure black, no shadow darker than that can be drawn; cards, menus, and dialog boxes end up looking like they're floating on the same plane.

Material Design's Android component library states this decision explicitly: the baseline dark theme's background and surface colors are dark gray, not black, and the library says this increases the visibility of shadows. The library's default dark background and surface color is #121212; Google's dark theme design exercise gives the same value for the interface's bottommost layer.

The harshness of the contrast matters too. White text's WCAG contrast ratio against pure black is 21:1, the ceiling of the scale. The same white against #121212 gives about 18.7:1, still well above WCAG's strictest text threshold. A dark gray surface doesn't lose anything in readability; it just pulls back slightly from the extreme end of the scale. Many teams also write body text in a very light gray instead of pure white: #E0E0E0 gives about 14.2:1 against #121212.

The Material documentation also justifies this choice by saying it reduces eye strain in bright text. That's a health claim, and the evidence on dark theme's relationship to the eye is the subject of RM-05; for this lesson, shadow and depth are enough to justify the dark gray surface.

Surfaces that lighten as they rise

Since shadow is weaker in dark theme, surfaces need another signal to separate themselves from each other. Material's answer is to lighten surfaces slightly as they rise.

The Material Components documentation explains it this way: in dark theme, shadows are less effective because they create less contrast against a dark background; to compensate, surfaces become lighter and more colorful as they get closer to the default light source — that is, as they rise in elevation. The library used to do this with a semi-transparent layer placed on top of the surface, whose transparency increased with elevation. A current note in the documentation says this method has been replaced by a tonal surface color system.

An example with numbers: mix five percent white into the #121212 background and you get #1E1E1E; mix in eleven percent and you get #2C2C2C. If the background, a card, and a dialog box take these three values, the eye separates the three layers without needing any shadow. In the token structure, this becomes role names like "surface," "surface elevation one," and "surface elevation two"; in a light theme, these same names can bind to the same white or to very close light grays, and elevation is shown there with shadow instead.

This same approach puts a constraint on the other decisions in this lesson: because surfaces get lighter as they rise, the contrast of text and icons on the highest surface is a bit lower than on the background. White text against #2C2C2C gives about 14:1; that's not a problem. But colors sitting near the threshold can fall below it at the topmost elevation. That's why every color in dark theme is tested not just against the background, but against the lightest surface as well.

Desaturation

Most colors that work well in a light theme can't be used the same way in dark theme; the obstacle is both measurable and perceptual.

The measurable obstacle is contrast. A dark, saturated blue that reads well against a white background in light theme becomes unreadable against a dark background: the blue #1565C0 gives only about 3.3:1 against #121212, falling below WCAG's 4.5:1 threshold for body text. A lighter tone of the same blue, #90CAF9, gives about 10.7:1 against the same background.

The perceptual obstacle is visual vibration. Google's Material dark theme exercise writes that lighter variants are chosen in dark theme so the color system keeps its expressive power while maintaining adequate contrast, and adds that more saturated colors tend to visually "vibrate" against dark backgrounds, which makes them harder to read.

The state colors built in UX-02 go through this same transformation. The error red #D32F2F gives about 3.8:1 against #121212, and the success green #2E7D32 gives about 3.7:1; both fall below the text threshold. Their lighter tones, #EF9A9A and #A5D6A7, give about 8.7:1 and 11.4:1 against the same background. In dark theme, the "error" token binds to this lighter red; the role stays the same, the value changes. Keeping the hue family matters: the user still reads the lighter red as red, and the icon and text from UX-02 already stand alongside the color anyway.

For brand colors, this is a decision point. Lightening the brand blue for dark theme moves it away from the value in the brand's guidelines. This is where GT-10's record format helps: the lighter blue chosen for dark theme can be written into the guidelines as the brand's derived equivalent for the screen. Which tone gets chosen is the team's decision; the measurable part is that the chosen tone gives the required contrast against both the background and the highest surface.

Energy on OLED displays

A frequently cited reason for dark theme is battery savings. This reason depends on screen technology and brightness.

On backlit LCD screens, the light behind the panel stays on whether the image is dark or light, so dark theme's energy effect on these screens is limited. On OLED screens, dark pixels draw less power. A study presented at the 2021 MobiSys conference by Pranab Dash and Y. Charlie Hu of Purdue University measured how large this saving actually is. According to the university's announcement, switching from light theme to dark theme at a hundred percent brightness saved an average of between 39 and 47 percent, while in the 30-to-50-percent range that indoor automatic brightness usually stays in, the saving stayed at only between 3 and 9 percent.

This result also connects to the dark gray decision. A pure black pixel produces no light on OLED; #121212 produces some, but very little. Most of the energy gain comes from the background turning from a light surface into a dark one; the difference between pure black and a very dark gray is small next to that larger difference. The energy argument alone doesn't make pure black mandatory.

Example — profile photos on dark cards

A community app shows members' profile photos in round frames, inside elevated cards, in dark theme. Most of the photos were taken in the evening or in dim indoor settings, against a dark background.

The team runs the contrast calculation not just for text, but for the edges of the photos too. A dark skin tone sample, #4A2C1D, gives about 1.7:1 against pure black, 1.5:1 against #121212, and only 1.1:1 against #2C2C2C, the highest card surface. A light skin tone like #F1C7A9, by contrast, stays above 9:1 against the same surfaces. So a dark-skinned member's photo, taken against a dark background, starts to disappear at its edge inside an elevated card: the round frame merges into the surface, and the boundary of the face can only be read from the detail inside it. Surfaces that lighten with elevation don't ease this problem — they make it worse, because they move closer to the dark skin tone itself.

The fix is a token: a semantic role called "avatar edge" binds to a very thin, semi-transparent light line in dark theme, and to a semi-transparent dark line in light theme. The edge doesn't touch the inside of the photo; it only makes the boundary of the frame visible, independent of the skin tone in the photo. The team reviews the result again across each of the three surface levels, using members' photos from the lightest to the darkest skin tone sample, taken in daylight and at night. Whether the same photos have a problem in light theme too is checked separately: there, it's the light-skinned photos with a white background that sit near the threshold.

Common misconception

Summary

1. Dark theme is not the inverted form of light theme; the semantic tokens from UX-01 bind to different steps of the raw palette for a dark environment, and the components themselves don't change.
2. A dark gray such as #121212, instead of pure black, leaves room for shadow and elevation; surfaces lighten as they rise, and saturated colors are replaced with lighter, less saturated tones on a dark background because of readability and vibration.
3. The energy gain on OLED depends on brightness, large at high brightness and small at indoor brightness; every color is tested not just against the background but against the highest surface too, and dark-skinned photos are protected on dark surfaces with a separate edge token.

Test yourself

1. (Easy) What is Material Components for Android's default dark background and surface color?
2. (Easy) What is the basic feature that distinguishes an OLED display from a backlit LCD display?
3. (Medium) Why isn't a pure black background chosen in dark theme?
4. (Medium) Why can't the blue #1565C0, used in light theme, be used as a text color the same way in dark theme?
5. (Hard) According to the results of the Purdue study, under which condition is dark theme's energy argument strong, under which is it weak, and what does this mean for the choice between pure black and dark gray?
6. (Hard) Why do dark-skinned members need a separate edge token for profile photos on elevated cards in dark theme?

Answers

1. #121212 ("Dark gray instead of pure black").
2. Each pixel produces its own light and there's no backlight; dark pixels draw less power ("Energy on OLED displays").
3. A shadow is an area darker than the background, and it can't be drawn on top of pure black; cards, menus, and dialogs look like they're on the same plane, and the depth between surfaces disappears. White text reaches 21:1 against pure black, the ceiling of the scale; a dark gray keeps readability at about 18.7:1 against #121212 while leaving room for surfaces to lighten as they rise ("Dark gray instead of pure black").
4. It gives about 3.3:1 against #121212 and falls below the 4.5:1 threshold for body text; saturated colors also appear to vibrate against a dark background. A lighter tone of the same blue, #90CAF9, gives about 10.7:1 ("Desaturation").
5. It's strong at a hundred percent brightness, with an average saving of 39–47 percent, and weak at the indoor 30–50 percent brightness range, with only 3–9 percent. Most of the gain comes from the background turning from light to dark; the difference between pure black and a very dark gray is small next to that, so the energy argument alone doesn't make pure black mandatory ("Energy on OLED displays").
6. A dark skin tone like #4A2C1D gives about 1.1:1 against the #2C2C2C surface, and the photo's edge merges into the surface; the surface lightening with elevation makes the problem worse because it moves closer to the dark skin tone. A thin, semi-transparent edge makes the boundary visible independent of the skin tone in the photo ("Example — profile photos on dark cards").

Sources

• Material Components for Android, "Dark theme" documentation and color resources (design_dark_default_color_background).
• Google Codelabs, "Design a dark theme with Material and Figma."
• Dash, P., and Hu, Y. C., "How much battery does dark mode save?," MobiSys 2021, pp. 323–335.
• Purdue University Elmore Family School of Electrical and Computer Engineering, "Dark mode may not save your phone's battery life as much as you think, but there are a few silver linings," July 28, 2021.
• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2."

Next step

UX-04 goes inside a single component: it discusses the color layers that separate a button's hover, pressed, keyboard-focus, and disabled states from each other, how to keep a focus ring visible on both light and dark surfaces, and how far a dimmed element can be faded and still stay readable. UX-05 hands the source of the theme over to the user: it asks how an entire interface's tonal palette can be generated from a wallpaper photo, and what that costs in brand recognition.