Dark Mode Color Generator: Mobile App Guide

A dark mode color generator workflow starts with your existing semantic roles, not an inverted screenshot: set a near-black surface such as Material Design’s #121212 baseline, create higher-elevation surfaces with progressively lighter tones, then reduce brand-colour saturation before assigning it to text, icons, and controls. Avoid #000000 for standard app surfaces because OLED near-black transitions can smear during motion and bright text can produce halation for people with astigmatism. Re-test every foreground/background pair; light-mode pairs routinely fail when inverted.

Key takeaways

•Material Design documents #121212 as a dark-theme surface baseline.
•WCAG 2.2 AA requires 4.5:1 contrast for normal-size text.
•WCAG 2.2 AA permits 3:1 contrast for large text.
•WCAG 2.2 requires 3:1 contrast for graphical objects and user-interface components.
•Material dark themes communicate elevation with lighter surface tones, not stronger drop shadows.

This guide is for mobile UI/UX designers, founders, and engineers who already maintain a light-theme colour palette and screen components.

Time: 45 minutes · You'll need: Your current light-theme colour tokens or style sheet, A contrast checker that reports WCAG 2.2 ratios, iOS Simulator and Android Emulator, At least one OLED phone for motion testing, A source image, if you want to extract starting colours manually

What's on this page

•Inventory the light-theme screen roles
•Set the dark mode design surface baseline
•Build elevation with lighter surface tones
•Mute brand colours for dark surfaces
•Re-run contrast checks on every pair
•Reference table

•Common mistakes
•FAQs

Deriving a dark mode palette, step by step

1. Inventory the light-theme screen roles

List semantic roles before changing a hexadecimal value. At minimum, record surface, surfaceVariant, onSurface, primary, onPrimary, outline, error, and disabled-content roles. Inspect three representative screens: a content list, a form, and a destructive confirmation sheet. This exposes colours that are carrying state rather than decoration.

Do not create a dark token named after its light counterpart, such as blue-500-dark. Name the job instead: primary, onPrimary, or focusRing. A dark theme mobile app needs the same role to remain identifiable when its hue, tone, and saturation change. Keep the light palette beside the new token sheet so designers and engineers can compare each role rather than attempting a one-click inversion.

If you are extracting a starting palette manually, sample a photograph with an eyedropper, write down 5 to 8 candidate colours, and assign each one to a role only after contrast testing it. The result is a role map, not yet a shippable dark palette.

Tip: Keep destructive red separate from brand primary; a desaturated primary and an error colour need different recognition jobs.

2. Set the dark mode design surface baseline

Set the main app surface to a near-black, not automatic #000000. Material Design documents #121212 as its dark-theme surface baseline. Use it as a practical starting value for full-screen backgrounds, then derive any platform-specific system bars from the same surface family.

Pure black creates the sharpest possible boundary against white or near-white text. On OLED panels, transitions involving near-black pixels can show black smearing during scrolling or animation; bright content on a black field can also appear to bleed or halo for users with astigmatism. These effects vary by panel and viewer, but they are a reason to test #000000 rather than treating it as the default premium choice.

Reserve true black for a deliberate visual requirement, such as an immersive media viewer, and test it on an OLED device with scrolling white text. For a standard settings, finance, messaging, or commerce screen, begin at #121212 and tune from there.

Tip: Test a scrolling list with small secondary labels; motion reveals near-black smearing that static design reviews miss.

3. Build elevation with lighter surface tones

Replace the light-theme habit of adding a darker shadow under every raised card. In dark mode, shadows have little visible range against a near-black canvas. Material Design’s dark-theme behaviour is tonal elevation: components at higher elevation use lighter surface tones so the hierarchy remains visible.

Create at least three surface roles: base surface, raised surface, and modal or prominent surface. Use the base #121212 surface as the reference, then make raised layers visibly lighter while keeping their hue family consistent. Apply those roles consistently: a bottom sheet and dialog should read above page content; a selected card should read above an unselected card; a navigation container should not compete with a modal.

Do not solve missing hierarchy by adding a bright border to every card. Borders are useful for input fields, selection, and grouped content, but a screen full of outlines becomes noisy. Compare the hierarchy in grayscale before restoring brand colour.

Tip: If two adjacent containers need different elevation, change their surface tones before introducing a shadow token.

4. Mute brand colours for dark surfaces

Start from the existing brand hue, then reduce saturation and adjust lightness until it reads calmly against the new surface. Highly saturated light-theme accents can appear to vibrate against a dark background, especially when placed beside near-white text or repeated across dense lists. This is most visible with saturated blues, magentas, and greens.

Make separate tokens for primary, onPrimary, and primaryContainer; never assume a light-theme primary can keep all three jobs. Test the primary token on a filled button, selected navigation item, focused text field, and a compact status badge. A colour that works as a 48 dp touch target can be too intense as a thin selected-state indicator.

Use the same manual sequence when deriving colours from an image: sample a brand candidate, lower its saturation, assign it to one semantic role, then test it on the actual mobile components. Do not preserve a sampled colour unchanged merely because it matches a logo.

Tip: Keep brand recognition in the hue family, not in maximum chroma; users can recognise a muted blue primary without a neon blue screen.

5. Re-run contrast checks on every pair

Treat dark mode as a new contrast audit. Inverting a light pair does not preserve its relative luminance, and a light-mode-passing pair can fail once text, icons, disabled states, overlays, or container tones change. Check every foreground against the exact surface behind it, including text over raised cards and icons inside filled buttons.

For WCAG 2.2 AA, normal text requires at least 4.5:1 contrast and large text requires at least 3:1. Non-text user-interface components and graphical objects required to understand or operate the interface need 3:1 against adjacent colours under Success Criterion 1.4.11. Check placeholder text, selected tab labels, error messages, focus indicators, and disabled controls separately; they often use tokens not seen in primary screen flows.

Test the final token set in iOS and Android system dark appearance, then inspect screens at the smallest supported text size and with larger accessibility text. Record the tested pair and ratio beside each token decision so a later brand refresh does not silently undo it.

Tip: Do not count a subtle shadow as component contrast; test the visible control boundary or its filled area against the adjacent surface.

Reference table

Dark-theme mobile colour checks

Item	Requirement or baseline	Use on screen
Main dark surface	#121212	Material baseline
Normal text	4.5:1 minimum	WCAG 2.2 AA
Large text	3:1 minimum	WCAG 2.2 AA
UI component boundary	3:1 minimum	Required controls

Do it with the free Color Picker from Image

Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.

Open the Color Picker from Image → — free, no sign-up.

Common mistakes

Inverting every light-theme hexadecimal value.

Keep the semantic roles and derive new values for each role. Inversion produces uncontrolled luminance, saturation, and contrast relationships.

Using #000000 as the default surface across every screen.

Start standard app surfaces at Material Design’s #121212 baseline. Test any true-black exception on an OLED phone while scrolling high-contrast content.

Adding stronger black shadows to show elevation.

Use lighter surface tones for raised layers in the dark theme. Keep shadows secondary because they are hard to perceive on near-black surfaces.

Reusing a saturated light-theme primary unchanged.

Reduce saturation, then test the result in selected, filled, and compact states. A colour can pass contrast and still create visual vibration.

Frequently asked questions

Should I use pure black for a dark theme mobile app?

No, use a near-black surface for most dark-theme mobile app screens and reserve #000000 for tested immersive cases. Material Design documents #121212 as a dark surface baseline. Pure black maximises the edge contrast of bright text, can expose OLED near-black smearing in motion, and can intensify perceived halation for some people with astigmatism.

What is the best dark mode palette for an existing app?

The best dark mode palette preserves semantic roles while assigning each role a newly tested dark-theme value. Start with a near-black surface, make elevated surfaces lighter, mute high-chroma brand colours, and test each foreground-background pair. Do not invert the light palette, because inversion does not preserve contrast or component hierarchy.

How do I create elevation in dark mode design?

Create elevation in dark mode design by using lighter surface tones for higher layers rather than relying on darker shadows. A dialog, bottom sheet, or raised card should use a distinct elevated surface token above the base near-black surface. Check the hierarchy in grayscale; if it disappears, adjust surface tones before adding borders.

Do I need to recheck contrast after making a dark theme?

Yes, every dark-theme foreground and background pairing needs a new WCAG contrast check. WCAG 2.2 AA requires 4.5:1 for normal text, 3:1 for large text, and 3:1 for required user-interface components against adjacent colours. Include labels on elevated cards, disabled states, icons, focus indicators, and text over filled buttons.

Can I use a dark mode color generator from an image?

Yes, a dark mode color generator can provide candidate hues from an image, but it cannot replace role assignment and contrast testing. Extract a small palette, choose a near-black surface independently, desaturate candidates that feel too intense, and assign them to roles such as primary, error, and on-surface. Verify each final screen pairing against WCAG 2.2.

Where this leaves you

A useful dark theme is a second colour system, not a photographic negative of the light theme. Keep the same semantic roles, begin with a near-black surface such as #121212, expose elevation through lighter layers, and calm brand accents before they reach production screens. The audit is only complete after every text, icon, component, state, and overlay pairing has been checked in its actual context. Your next action is to make a token table for one representative mobile screen and record the contrast ratio beside every on-* token before propagating the palette to the rest of the app.

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

•Contrast Checker — Test any pair against WCAG 2 and the newer APCA method, with a colour-blind check and the nearest passing colours.
•Colour Blindness Simulator — See your screens through every type of colour vision deficiency at once, and download the whole comparison.
•Contrast Checker: Meet WCAG in Mobile Apps — Use a contrast checker to audit WCAG 2.2 mobile text, controls, placeholders and states, t
•Color Blindness Simulator: Test App Colors — Use a color blindness simulator to test iOS and Android screens, fix red-green status fail
•Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery