Dark Mode UI Design: Colors, Contrast and Component States

A dark theme needs readable text, distinct controls and clear relationships between surfaces. Changing a white background to black is only the starting point. This guide explains how to choose color roles and reuse them across light and dark designs.

In Pixso’s shared design-system workspace, organize reusable components and styles around their purpose. Agree on the names and expected appearance with developers before applying the theme across many screens.

Choose a dark background and readable text

A dark interface needs a deliberate relationship between its background, surfaces and text. Pure black is one possible background; dark gray is another. Choose based on the content, display context and separation required between surfaces, then test the actual foreground/background combinations.

There is no single mandatory hex value for a dark theme. A commonly used dark gray can be a starting point, but its popularity is not evidence that every adjacent color will be readable.

Some readers find very bright text on dark backgrounds uncomfortable, while others prefer it. Avoid universal medical claims about a color pair. Provide readable text, respect user preferences and assess the interface in the conditions in which it will be used.

Use a small set of surface and text roles. A base canvas, a card and an overlay may need different fills or borders so their boundaries remain visible. Test primary and secondary text separately; making secondary text faint can undermine readability even when headings have ample contrast.

Adapt brand colors by their role

A brand accent that works on a light page may need a different value on a dark surface. Evaluate the accent in its actual roles: text link, button background, selected control or decorative shape. Those uses have different surrounding colors and requirements.

Adjust lightness or saturation when testing shows a problem, rather than desaturating every color by default. Keep a recognizable brand relationship while choosing values that remain readable and distinguishable in the dark theme.

Reserve visual emphasis for the most useful actions and states. Check logos and illustrations as well as controls: an asset with a fixed white background may need an appropriate dark-theme version, while another image can remain unchanged.

Keep theme decisions together

Shared components and named color styles make changes easier to review. Keep a representative light and dark screen together, so changing a label or component structure does not leave one version unexplained.

The design tool helps maintain the visual specification; the application still needs theme-selection logic and implementation. Do not treat a successful canvas preview as proof that the running product changes every state correctly.

Keep the approved theme values, component examples and unresolved questions beside the design. Team comments help discuss a specific surface or state, while a clear handoff identifies which version should be implemented.

Name colors by purpose

Color names are easier to maintain when they describe purpose. A larger system may separate raw values, semantic roles and component-specific roles. A small product can begin with a shorter role set instead of creating three layers it does not need.

Raw values name the available colors, such as Gray-900 or Blue-500. Their names describe the palette; they do not explain whether a value belongs on a page background or a selected control.

Semantic roles describe a job: page background, elevated surface, primary text, muted text or critical message. Each role can have a suitable value for light and dark appearance without changing its meaning.

Component roles are useful when a control needs a more specific decision, such as the border of a focused input. Add them where they clarify a real behavior, rather than making a separate token for every instance.

Document both values for each shared role and apply corresponding Color Styles to representative frames. Agree on how these names map to the implementation. A role table can communicate the specification even when the design file and application use different storage formats.

After a value changes, review the components that use it. A color that improves a page-level label may make a label inside an accent button worse. Shared styles reduce repeated editing, but they do not remove the need to inspect combinations.

The next implementation step is to use design tokens for theme switching, keeping the meaning of each color consistent while its value changes between modes.

Separate surfaces and overlays

Depth must remain understandable in a dark interface. In a light interface, a shadow can help separate an overlay from the page underneath; it is one cue rather than a requirement for every overlay.

A shadow can be hard to distinguish against a dark background. Separate surfaces with a suitable combination of fill, border, spacing and shadow rather than relying on one dark shadow to carry the entire hierarchy.

One possible hierarchy uses a darker base and slightly lighter cards and overlays. Treat those as relationships to evaluate, not fixed levels that every product must follow. Compare the overlay against all surfaces it can cover, including images and accent areas.

A subtle border can clarify the edge of an overlapping menu. Its actual composited color depends on opacity and the background beneath it, so evaluate the rendered result. Avoid choosing a low-opacity white border merely because it looks acceptable on one sample card.

Check component states and contrast

Review the components used by the dark theme, including buttons, form fields, tables and dialogs. Check the states relevant to each component, such as default, hover, focus, pressed, selected, disabled and error. Changing the main frame’s background alone does not cover these combinations.

For WCAG 2.2 Level AA, normal text generally needs a contrast ratio of at least 4.5:1, while large text needs at least 3:1; the criterion defines exceptions. Use the W3C contrast guidance to identify which requirement applies, then measure the actual colors.

Use a contrast checker on each relevant foreground/background pair. Include selected, hovered, focused and error states rather than measuring only the default button. Explain errors with text and useful guidance, and distinguish states through more than color alone. A contrast result is one part of accessibility, not a complete accessibility pass.

Worked example: an appearance settings panel

Take a settings panel containing Light, Dark and System options, a short explanation and a save confirmation. This small screen exercises several roles without requiring a full dashboard redesign.

Test selecting Dark while System is active, returning to System, and re-opening the panel. If saving fails, the UI must not silently show the unsaved option as permanent. Keep the selected preference separate from the appearance currently displayed by a preview.

Next open an overlay above the panel. Its boundary, close action and focus state should still be clear. This exposes combinations that a palette swatch sheet cannot demonstrate.

Specify theme behavior for development

Decide how the product chooses its appearance. A useful option set is Light, Dark and System: System follows the device preference, while an explicit choice can override it. Specify what happens on the next visit and when the operating-system setting changes.

Give developers the color roles for both themes, the selection behavior and the agreed design version. Keep these details beside the relevant Pixso screens. Developers still need to implement persistence, system preference handling and the actual component states.

Start with one representative screen that includes ordinary text, an input, a selection and an overlay. Once its states work together, extend the same roles to the remaining screens and review exceptions such as charts, illustrations and embedded content.