CSS Dark Mode Styling

What You Learn From This Page

• How dark mode works as a coordinated theme rather than a collection of inverted colors.
• How to model light and dark themes with semantic CSS custom properties.
• How to combine system preference with explicit Light, Dark, and System choices.
• How to persist a preference and prevent a flash of the wrong theme during startup.
• How to theme controls, links, forms, images, SVG, tables, code, charts, and third-party content.
• How to protect contrast, focus visibility, motion preferences, performance, and maintainability.

Introduction

Dark mode is a visual theme that uses predominantly dark surfaces with light foreground content. A polished implementation is not a black background placed behind white text. It is a coordinated design system in which surfaces, text levels, borders, controls, illustrations, charts, shadows, and interaction states remain readable and consistent under a different luminance model.

Users may choose dark mode to reduce glare in dim surroundings, match an operating-system preference, improve comfort, or simply use an appearance they prefer. The interface must still communicate hierarchy and state clearly. Dark mode is therefore an accessibility and product-quality concern as much as a styling feature.

The most maintainable approach separates semantic design decisions from literal color values. Components ask for a page background, primary text, muted text, border, accent, or danger color. The active theme supplies suitable values for those roles. That architecture allows the same markup and component CSS to serve light mode, dark mode, and future themes without duplicating the application.

Dark Mode Is a Theme System

A theme coordinates many visual properties. Color is the most obvious part, but the system also controls elevation, image treatment, native form controls, focus indicators, syntax highlighting, data visualization, and browser chrome. Changing only background-color and color leaves bright cards, invisible borders, low-contrast placeholders, and assets designed for a white canvas.

Begin by inventorying every visual role in the interface. Identify canvas and surface levels, primary and secondary text, borders, links, focus rings, disabled states, status colors, shadows, overlays, and data-series colors. Theme those roles centrally, then test complete workflows rather than isolated screenshots.

Detecting the System Preference

The prefers-color-scheme media feature reports whether the user has requested a light or dark appearance at the operating-system or browser level. It provides a useful automatic default without requiring JavaScript.

:root {
  --page-bg: #ffffff;
  --surface: #f8fafc;
  --text: #172033;
}

@media (prefers-color-scheme: dark) {
  :root {
    --page-bg: #10141c;
    --surface: #181e29;
    --text: #f2f5f9;
  }
}

The media query reacts when the system preference changes. It is an excellent baseline, but it is not a complete preference model because a user may want one website to differ from the operating system. A mature interface adds an explicit control while retaining System as an option.

Start With Semantic Custom Properties

Semantic custom properties describe purpose rather than a literal shade. Names such as --color-bg, --color-text-muted, and --color-border tell a component why it uses a value. Names such as --gray-900 describe only the palette and may become misleading when a dark theme maps the role to a light value.

:root {
  --color-canvas: #ffffff;
  --color-surface-1: #f8fafc;
  --color-surface-2: #eef2f7;
  --color-text: #182230;
  --color-text-muted: #526071;
  --color-border: #c9d2df;
  --color-accent: #0759b8;
  --color-focus: #006fe6;
}

Components should consume these role tokens rather than embedding theme-specific colors. Palette tokens can still exist beneath the semantic layer, but application rules should normally depend on semantic names.

Override Tokens, Not Components

A dark theme should usually replace values at a central scope. Rewriting every component under a dark media query creates duplicated selectors and makes new components easy to forget.

@media (prefers-color-scheme: dark) {
  :root {
    --color-canvas: #0f141c;
    --color-surface-1: #171e29;
    --color-surface-2: #212a38;
    --color-text: #f3f6fa;
    --color-text-muted: #b8c3d1;
    --color-border: #465368;
    --color-accent: #78b7ff;
    --color-focus: #8ac2ff;
  }
}

body {
  color: var(--color-text);
  background: var(--color-canvas);
}

A card, dialog, table, and navigation bar can all reference the same tokens. When the root values change, those components adapt without knowing which theme is active.

Build a Surface Hierarchy

Light themes often communicate elevation with shadows on a white or pale canvas. Strong black shadows are less informative on dark backgrounds, so dark themes commonly use controlled differences in surface lightness plus restrained borders. A canvas can be the darkest level, ordinary cards slightly lighter, and elevated menus or dialogs lighter again.

Do not make every dark surface identical. Without separation, cards, inputs, sidebars, and overlays visually merge. At the opposite extreme, dramatic differences make the interface look fragmented. Use a small, documented set of surface levels and assign each component according to its structural role.

Design Text Hierarchy Carefully

Pure white text on pure black creates extreme contrast that some users find harsh, especially across long articles. A near-white primary text color on a very dark gray surface often reads more comfortably. Secondary text must remain clearly legible, not disappear into the background.

Define primary, secondary, muted, and disabled roles deliberately. Verify normal text and large text against the actual surface behind them. Opacity-based text can produce unexpected results when moved across surfaces, so explicit theme tokens are often easier to validate than a translucent white used everywhere.

Choose Accent and Link Colors Per Theme

An accent that works on white may appear dull, vibrate, or fail contrast on a dark surface. Dark mode usually needs a lighter accent variant. Links should remain recognizable through color and, where appropriate, underlining or another non-color cue.

a {
  color: var(--color-accent);
  text-decoration-thickness: 0.1em;
  text-underline-offset: 0.18em;
}

a:hover {
  text-decoration-line: underline;
}

a:focus-visible {
  outline: 3px solid var(--color-focus);
  outline-offset: 3px;
}

Test visited, hover, active, and focus states separately. A visible default link can still become unreadable when hovered if a light-theme hover color was left unchanged.

Borders, Shadows, and Elevation

Border tokens need enough contrast to reveal component boundaries under bright displays and low-quality screens. Avoid borders so subtle that they disappear at full brightness. Dark-theme shadows should be soft and purposeful; a thin lighter border may communicate separation more reliably than a large black blur.

.card {
  color: var(--color-text);
  background: var(--color-surface-1);
  border: 1px solid var(--color-border);
  box-shadow: 0 0.5rem 1.5rem rgb(0 0 0 / 0.16);
}

Overlays and dialogs also need a backdrop that distinguishes the active layer without hiding the context completely. Test nested surfaces so a card inside a dialog does not accidentally use the same level as its parent.

Let Components Consume Theme Roles

Theme-aware component CSS should describe structure and meaning. It should not contain parallel light and dark blocks unless the component has an exceptional visual need.

.notice {
  color: var(--color-text);
  background: var(--color-surface-2);
  border-inline-start: 0.3rem solid var(--color-accent);
  padding: 1rem;
}

.notice-title {
  color: var(--color-text);
  font-weight: 700;
}

This makes a component reusable in any theme scope. It can even appear in a dark preview inside an otherwise light page if the tokens are overridden on that container.

Offer Light, Dark, and System Choices

A binary toggle cannot express the difference between following the system and forcing a particular appearance. A three-choice control is clearer: Light always selects the light theme, Dark always selects the dark theme, and System follows prefers-color-scheme.

Use a radio group, select menu, or segmented control with accessible labels. The current selection must be available to assistive technology and should not be communicated by an icon alone. System is often the best default for a first visit because it respects an existing user preference.

Represent an Explicit Theme in Markup

A data attribute on the root element creates a clear styling hook and makes the active override easy to inspect.

<html lang="en" data-theme="dark">

:root[data-theme="light"] {
  --color-canvas: #ffffff;
  --color-text: #182230;
}

:root[data-theme="dark"] {
  --color-canvas: #0f141c;
  --color-text: #f3f6fa;
}

For System, remove the explicit attribute and allow the media query to decide. Another valid architecture writes data-theme="system" and handles it explicitly, but the team should choose one model and document its precedence.

Define Theme Precedence

Precedence prevents explicit preferences from being overwritten by an automatic media query. Base tokens can define light mode, the system dark query can apply only when no explicit theme exists, and explicit root selectors can appear later or carry a deliberate cascade-layer order.

@media (prefers-color-scheme: dark) {
  :root:not([data-theme]) {
    --color-canvas: #0f141c;
    --color-text: #f3f6fa;
  }
}

:root[data-theme="dark"] {
  --color-canvas: #0f141c;
  --color-text: #f3f6fa;
}

The important rule is conceptual: an explicit user choice wins, while System remains reactive to operating-system changes.

Apply the Preference With JavaScript

JavaScript is useful for reading a saved choice and updating the root attribute. Styling still remains in CSS.

function applyTheme(preference) {
  const root = document.documentElement;

  if (preference === "system") {
    root.removeAttribute("data-theme");
  } else {
    root.dataset.theme = preference;
  }
}

themeControl.addEventListener("change", (event) => {
  const preference = event.target.value;
  localStorage.setItem("theme-preference", preference);
  applyTheme(preference);
});

Validate stored input before applying it. Unexpected values should fall back to System rather than becoming selectors or application state.

Persist the User Choice

localStorage is a practical option for a theme preference because the setting is small and should survive navigation and browser restarts. It remains scoped to the site and browser profile. If a signed-in product needs the same preference across devices, store it in the user profile on the server as well.

Storage can be unavailable or restricted, so persistence should be an enhancement rather than a requirement for rendering. Wrap reads and writes defensively, use System when no usable value exists, and never block the entire interface because preference storage failed.

Prevent a Flash of the Wrong Theme

If the page first paints in light mode and later-running JavaScript switches it to dark, the user sees a bright flash. The preference must be known before the main stylesheet paints. A very small inline script in the document head can read the saved value and set the root attribute immediately.

<script>
  try {
    const saved = localStorage.getItem("theme-preference");
    if (saved === "light" || saved === "dark") {
      document.documentElement.dataset.theme = saved;
    }
  } catch (error) {
    // System preference remains the fallback.
  }
</script>

Keep this startup code tiny and stable. Sites with strict Content Security Policy rules may use a nonce, approved hash, or server-rendered attribute instead of an unrestricted inline script.

Use the color-scheme Property

The color-scheme property tells the browser which schemes an element supports. This helps native controls, scrollbars, form widgets, and browser-provided surfaces use a compatible appearance.

:root {
  color-scheme: light dark;
}

:root[data-theme="light"] { color-scheme: light; }
:root[data-theme="dark"] { color-scheme: dark; }

This property does not design the application. It complements custom theme styles by improving browser-owned UI. Test native controls in every supported browser because their rendering is not identical.

Theme Form Controls Completely

Inputs, textareas, selects, checkboxes, and buttons need readable text, surfaces, borders, placeholders, focus states, validation states, and disabled states. A dark page with an unthemed bright input feels unfinished and can create glare.

input,
select,
textarea {
  color: var(--color-text);
  background: var(--color-surface-1);
  border: 1px solid var(--color-border);
}

::placeholder {
  color: var(--color-text-muted);
  opacity: 1;
}

Do not rely only on browser defaults. Test autofill, password-manager overlays, date controls, search cancel buttons, selected options, and validation messages where those features appear.

Preserve Strong Focus Indicators

A focus ring must be visible against every surface and component state. One color may work on the canvas but disappear on an accent button. Consider a two-color technique, an outline plus offset, or component-specific semantic focus tokens where necessary.

:focus-visible {
  outline: 3px solid var(--color-focus);
  outline-offset: 3px;
}

.primary-button:focus-visible {
  outline-color: var(--color-canvas);
  box-shadow: 0 0 0 5px var(--color-focus);
}

Keyboard testing should cover menus, dialogs, forms, tables, and theme controls in both modes. Focus visibility is not optional decoration.

Design Semantic Status Colors

Success, warning, information, and danger colors need foreground, background, and border variants for each theme. Reusing saturated light-theme fills can overwhelm a dark interface, while dark red text may become unreadable.

Color should not be the only status cue. Include an icon with accessible meaning, a clear label, or explanatory text. A validation error should say what failed and how to correct it; a red border alone is insufficient in either theme.

Handle Disabled and Read-Only States

Disabled content often uses reduced contrast, but it should remain identifiable when users need to understand available options. Avoid reducing opacity so much that labels vanish. Read-only and disabled are different states and should not look identical if their behaviors differ.

Pointer cursors, hover effects, focusability, and ARIA state must agree with the visual treatment. Theme changes should never make an interactive control appear disabled or make a disabled control appear active.

Adapt Raster Images Deliberately

Photographs usually should not be inverted. Product screenshots, diagrams, and illustrations may need a border, alternate asset, or adjusted surrounding surface. Transparent images designed for white backgrounds can contain pale details that disappear in dark mode.

Use image editing or alternate sources when the visual meaning requires it. Broad CSS filters such as invert() can distort brand colors, skin tones, screenshots, and embedded text. A filter is appropriate only when the asset has been tested for that transformation.

Provide Theme-Specific Picture Sources

The picture element can select an asset using the same color-scheme preference when separate illustrations are available.

<picture>
  <source
    srcset="architecture-dark.png"
    media="(prefers-color-scheme: dark)">
  <img
    src="architecture-light.png"
    alt="Application architecture with client, API, and database layers">
</picture>

An explicit website override may require JavaScript or attribute-driven source management because the media condition follows the system. Preserve the same informative alternative text when only the visual styling changes.

Use currentColor in SVG

Inline SVG icons can inherit the surrounding text color through currentColor. This allows icons to follow semantic foreground tokens without duplicate assets.

.icon {
  inline-size: 1.25rem;
  block-size: 1.25rem;
  color: var(--color-text);
}

.icon path {
  fill: currentColor;
}

Complex multicolor illustrations may still need theme-specific variables. Decorative SVG should not add unnecessary accessible names, while meaningful icons need an appropriate label through surrounding text or accessible SVG markup.

Protect Logos and Brand Assets

A dark wordmark may disappear on a dark header, and a white logo may vanish in light mode. Use approved light and dark brand variants rather than improvising colors. If only one asset exists, place it on a controlled neutral surface with sufficient padding and contrast.

Do not modify protected brand colors merely to fit the theme. Coordinate with the design system and preserve recognizability. Favicons and application icons may also need variants because browser and operating-system surfaces differ.

Theme Background Images and Gradients

Background imagery can dominate a dark interface if it remains bright. Use overlays, alternate crops, or separate assets while preserving foreground contrast. Gradients should support hierarchy, not hide insufficient token design.

Test text over every part of an image at responsive sizes. A dark overlay that works on one crop may expose a bright region after the image repositions on mobile. When readability is critical, place text on a solid semantic surface instead of relying on an unpredictable image.

Style Tables for Scanning

Tables need distinct header surfaces, visible row and column boundaries where needed, readable zebra patterns, and clear hover or selected states. Subtle light-gray separators often disappear after a theme switch.

table {
  color: var(--color-text);
  background: var(--color-surface-1);
  border-color: var(--color-border);
}

thead {
  background: var(--color-surface-2);
}

tbody tr + tr {
  border-block-start: 1px solid var(--color-border);
}

Sticky headers, sort icons, selected rows, and inline controls should all be evaluated in context rather than as isolated colors.

Theme Code Blocks and Text Selection

Code blocks frequently contain their own syntax palette. Each token category must remain readable against the code surface, and no essential distinction should depend on hue alone. Inline code also needs contrast inside paragraphs and table cells.

::selection {
  color: var(--selection-text);
  background: var(--selection-bg);
}

pre,
code {
  color: var(--code-text);
  background: var(--code-bg);
}

Selection colors are easy to overlook. Test selected links, headings, and code to ensure both selected foreground and background remain visible.

Theme Charts and Data Visualization

Charts require more than a dark plot background. Axes, grid lines, labels, legends, tooltips, annotations, and every data series need theme-aware colors. Series must remain distinguishable for users with color-vision differences and on printed or low-quality displays.

Expose chart colors as semantic data tokens and pass computed values to canvas-based libraries when CSS variables are not read automatically. Re-render or update the chart when the active theme changes. Include patterns, markers, line styles, or direct labels where color alone cannot communicate the series.

Handle Canvas Content

A canvas does not automatically restyle when CSS variables change because its pixels were drawn by script. The drawing code must read the active theme, select suitable values, clear the canvas, and draw again. The same rule applies to WebGL scenes and generated bitmap previews.

Keep theme values in a shared interface so DOM and canvas components do not drift. Test zoom, high-density displays, and exported chart images because the exported background may otherwise become transparent or retain the previous theme.

Control Third-Party Widgets and Iframes

Embedded content may not inherit your CSS. Prefer providers that expose a documented theme option or honor prefers-color-scheme. Pass the active choice through an approved configuration API and update it when the user switches themes.

Cross-origin iframe contents cannot be arbitrarily restyled from the parent page. Place the embed inside an appropriate surface, reserve its dimensions, and accept that some provider UI may remain light. Do not use unsafe filters to conceal an integration limitation.

Use Theme Transitions With Restraint

A short transition can soften an explicit theme change, but transitioning every property on every element is expensive and can create distracting motion. Limit transitions to color-related properties on a manageable set of containers and components.

body,
.card,
.dialog {
  transition:
    background-color 160ms ease,
    color 160ms ease,
    border-color 160ms ease;
}

@media (prefers-reduced-motion: reduce) {
  body,
  .card,
  .dialog {
    transition: none;
  }
}

Avoid transitions during the initial page load, where they can make first-paint correction more obvious.

Build an Accessible Theme Control

The control needs a visible label, clear options, a programmatic name, keyboard access, and an exposed selected state. A sun or moon icon can supplement text but should not be the only indication. The label should describe the choice, such as Appearance, rather than an ambiguous command.

When a selection is applied immediately, users should see the visual result and the control state should remain synchronized. Avoid moving keyboard focus after the change. If the choice is saved to an account, communicate errors without reverting silently.

Respect Contrast and Non-Color Meaning

Contrast must be measured for each foreground and background pair in both themes. Test normal text, large text, icons, form boundaries, focus indicators, disabled controls, status messages, charts, and selected states. A token may pass on one surface and fail on another.

Do not infer that dark mode is automatically accessible. Very bright text can cause halation for some users, low-contrast gray can disappear, and saturated colors can be uncomfortable. Use labels, shapes, icons, patterns, and placement so meaning survives when color perception or display quality differs.

Consider Forced Colors and User Styles

Some users rely on forced-color modes or custom styles rather than your dark palette. Use semantic HTML and system-friendly controls so essential structure survives. Avoid replacing every native appearance unless the custom version has complete states.

Test forced colors where supported. Use currentColor for important icons and borders when practical, keep focus visible, and do not use forced-color-adjust: none broadly. That property should be reserved for carefully tested cases where preserving a specific color is essential to understanding.

Keep Print Styles Independent

A page viewed in dark mode should not necessarily print with a dark background. Printer ink, PDF readability, and document conventions often favor a light print theme. Define print styles that use a white canvas, dark text, visible links, and suitable table borders.

@media print {
  :root {
    color-scheme: light;
    --color-canvas: #ffffff;
    --color-surface-1: #ffffff;
    --color-text: #111111;
    --color-border: #666666;
  }
}

Print preview should be included in theme testing, especially when the site offers PDF generation or downloadable learning material.

Organize Theme Authority With Cascade Layers

Cascade layers can make theme precedence explicit. Tokens can live in one layer while components consume them in another. Utility or override layers should not accidentally replace semantic theme values.

@layer reset, tokens, components, utilities;

@layer tokens {
  :root { --color-canvas: #ffffff; }
  :root[data-theme="dark"] { --color-canvas: #0f141c; }
}

@layer components {
  body { background: var(--color-canvas); }
}

Layers organize authority, while custom properties carry configuration. They solve different problems and work well together.

Scope Themes for Previews and Embedded Areas

Theme tokens can be overridden on a container to display a preview, editor canvas, or embedded application area in another mode.

.theme-preview[data-theme="dark"] {
  --color-canvas: #0f141c;
  --color-surface-1: #171e29;
  --color-text: #f3f6fa;
  --color-border: #465368;
  color-scheme: dark;
}

Components inside the preview must rely on inherited semantic tokens rather than root-only selectors. Portals, popovers, and dialogs rendered elsewhere in the DOM need special attention because they may not inherit from the apparent visual parent.

Server Rendering and Content Security Policy

Server-rendered applications can place the known account preference on the root element before sending HTML. This produces the correct first paint and avoids a client-only correction. Anonymous visitors can still use the system preference.

A strict Content Security Policy should be designed alongside startup theme logic. Use a nonce or hash for a minimal inline initializer, serve an allowed external initializer early, or render the theme attribute on the server. Do not weaken script policy merely to remove a visual flash.

Performance Considerations

Theme variables are generally inexpensive, but broad selectors, universal transitions, large alternate assets, and repeated JavaScript style writes can add cost. Change one root attribute and let the cascade update dependent values. Avoid walking the DOM to assign colors element by element.

Load only the assets needed for the active presentation where practical, reserve image dimensions to prevent layout shift, and keep the pre-paint preference script small. Measure startup and theme switching on lower-powered mobile devices, not only a fast development machine.

Testing Matrix

Also test System while changing the operating-system preference, explicit choices after reload, storage failure, signed-in synchronization, browser zoom, high contrast, and content loaded after the initial render.

Debugging Theme Problems

Inspect the computed value of a failing property, then trace the custom property to the scope where it was defined. Check whether an explicit theme attribute exists, whether a media query matches, and whether cascade order or a fallback is replacing the intended token.

Search for hard-coded colors, inline styles, SVG fills, canvas drawing values, box shadows, gradients, and third-party configuration. Temporarily outline surface levels or print token values in a development panel. Debug the semantic role first; patching one component color can hide a missing system token.

Common Dark Mode Mistakes

• Inverting the entire page and corrupting images, brand colors, and status meaning.
• Using pure black and pure white everywhere without a readable hierarchy.
• Changing the page background while leaving cards, forms, tables, or dialogs bright.
• Using light-theme accent, hover, focus, and validation colors without retesting them.
• Building a toggle that cannot represent the System preference.
• Applying saved preferences after paint and causing a visible flash.
• Storing a choice without validating the value or handling unavailable storage.
• Using color as the only cue for errors, selection, chart series, or status.
• Animating every property on every element during a theme change.
• Forgetting canvas content, third-party widgets, print output, and dynamically inserted UI.

Migration Strategy for an Existing Site

Start with an audit rather than a global dark selector. List hard-coded colors and group them by purpose. Create semantic tokens for the canvas, surface levels, text levels, borders, accents, focus, status, code, and data visualization. Replace component literals gradually while preserving the current light appearance.

After the light theme is fully tokenized, define dark values centrally. Fix shared components before rare pages, then add explicit preference handling and first-paint logic. Run visual regression and accessibility tests at each stage. This sequence separates architectural work from dark-palette tuning and reduces one-off overrides.

Dark Mode Architecture Reference

Common Interview Questions

What is CSS dark mode styling? It is a theme architecture that supplies dark-surface values for semantic visual roles while preserving readable hierarchy, state, accessibility, and component behavior.

How does CSS detect a system dark preference? The prefers-color-scheme: dark media query matches when the user agent reports a dark color-scheme preference.

Why use semantic custom properties? They let components request roles such as surface, text, border, and accent without knowing the active theme's literal colors.

What should win: system preference or a website choice? An explicit user choice should win. System should remain the default and should react when no explicit override exists.

What does color-scheme do? It informs the browser which schemes an element supports so browser-owned controls and surfaces can use an appropriate appearance. It does not replace application styling.

How can a site avoid a flash of light mode? Apply a validated stored preference before first paint through a small permitted head initializer or render the correct root attribute on the server.

Should images be inverted in dark mode? Not generally. Use tested alternate assets, controlled surfaces, or selective treatment; blanket inversion damages photographs and brand colors.

How should dark mode be tested? Test both themes across startup, interaction states, responsive layouts, forms, media, charts, accessibility modes, storage conditions, print, and dynamic content.

Practical Review Checklist

• Inventory canvas, surfaces, text levels, borders, accents, focus, and status roles.
• Move literal component colors behind semantic custom properties.
• Define a small, consistent surface hierarchy for each theme.
• Use the system preference as a default and offer Light, Dark, and System choices.
• Make an explicit user choice override the automatic media query.
• Persist only validated values and handle unavailable storage safely.
• Apply the saved choice before first paint or render it on the server.
• Declare an appropriate color-scheme for native browser UI.
• Test forms, placeholders, autofill, disabled states, and focus indicators.
• Provide theme-aware assets for images, SVG, logos, code, charts, and canvas.
• Use labels, icons, patterns, or text so color is never the only meaning.
• Verify contrast on every actual surface, not only against the page canvas.
• Limit transitions and honor the reduced-motion preference.
• Check third-party widgets, iframes, dynamically inserted content, print, and exports.
• Test system changes, reloads, narrow screens, zoom, keyboard use, and forced colors.
• Document tokens, precedence, ownership, and the supported theme test matrix.

Key Takeaway

Reliable dark mode comes from theme architecture, not from reversing a few colors. Semantic custom properties give components stable visual roles, prefers-color-scheme supplies a respectful default, and an explicit Light, Dark, or System choice gives users control. Early preference application, color-scheme, and careful asset handling make the experience feel complete from the first paint.

The quality of the dark theme is measured across the whole interface: text hierarchy, boundaries, forms, focus, errors, images, code, charts, overlays, third-party content, motion, print, and accessibility settings. Centralize decisions, preserve non-color meaning, test every state in both themes, and keep components dependent on semantic roles. That approach produces a dark mode that remains readable, maintainable, and consistent as the product grows.