---
title: How do I test dark mode across different devices and operating systems?
description: Learn how to test dark mode across devices, browsers and operating systems, covering colour shifts, contrast, automation and QA checklists.
image: https://weareaffective.com/hubfs/learning-centre-images/how-do-i-test-dark-mode-across-different-devices-and-operating-systems.webp
---

[Skip to content](https://weareaffective.com/learning-centre/how-do-i-test-dark-mode-across-different-devices-and-operating-systems#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# How do I test dark mode across different devices and operating systems?

 Table of Contents

Dark mode looks simple from the outside. A user flips a switch, the background goes dark, the text goes light, and the product feels more comfortable to use at night. But the moment you start testing it across real devices, you find that what looks polished on one screen falls apart on another. Colours shift. Shadows disappear. Images that work perfectly in light mode become muddy or invisible. And because users experience your product across dozens of different operating systems, screen types, and browsers, a dark mode that only works in one environment is, practically speaking, a dark mode that does not work.

> Dark mode done well is a trust signal for users who notice when a product feels considered and complete.

We see this pattern often when a team has built dark mode as a single design decision rather than a testing discipline. The design looks right in Figma. It looks right in Chrome on a MacBook. Then it lands on an OLED Android device and the contrast ratios are wrong, or on Windows where the system accent colour bleeds into components it was never meant to touch. The gap between [what was designed and what was shipped](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) is almost always a testing gap.

This article is a practical guide to closing that testing gap. We cover which devices and platforms to prioritise, how to structure a test environment, what to actually look for beyond background and text colour, and how to build a process your team can repeat without starting from scratch each time.

## Why Dark Mode Behaves Differently Across Platforms

Each operating system handles dark mode through a different mechanism, and that is the root of most inconsistencies. iOS and macOS use the `prefers-color-scheme` media query but also apply system-level colour overrides that interact with app-level styling in ways that are not always predictable. Android interprets dark mode through Material You on newer versions, which dynamically generates a colour palette from the user's wallpaper. That palette can shift your carefully chosen brand colours into something you have never tested against.

Windows takes a different approach again. It has its own high-contrast mode, a separate dark mode setting, and an accent colour system that Windows apps and Electron-based products inherit. A fitness app built on a web wrapper will pick up that accent colour in scrollbars, toggles, and focus rings unless you have explicitly overridden it. Teams rarely do, because they tested in Chrome on macOS and never saw the issue.

#### Screen technology compounds the problem

OLED and AMOLED screens render true black pixels by switching them off entirely, which means a colour you specify as very dark but not quite black looks noticeably different on OLED than it does on an LCD panel. What reads as a sophisticated dark grey on a MacBook Pro becomes a visible mismatch next to component borders that do hit true black. Getting this right matters practically too: [PCloudy](https://www.pcloudy.com/blogs/test-dark-mode-across-devices/) reports that true black pixel usage on OLED displays can extend battery life by 30 to 60 percent, which is a real reason users care about dark mode beyond comfort.

#### Browsers add another layer

Even within the same operating system, Chrome, Safari, and Firefox interpret the `prefers-color-scheme` query slightly differently, and each has its own default stylesheet that dark mode interacts with. Form elements are a particular problem: inputs, dropdowns, and checkboxes often inherit browser-level dark styling that overrides your own CSS unless you have written explicit rules to prevent it.

## The Devices and Operating Systems You Actually Need to Cover

A realistic test matrix does not mean testing every permutation. It means identifying the combinations where failures are most likely and where the user base is large enough to make those failures costly. For most lifestyle brands, that means covering iOS on iPhone (current generation and one version back), Android on a mid-range device running Android 12 or later, macOS on Safari and Chrome, and Windows 10 and 11 on Chrome and Edge.

The mid-range Android device matters more than the flagship. A Samsung Galaxy A-series phone running One UI is used by far more people than a Pixel, and One UI's interpretation of Material You generates colour palettes that behave differently from stock Android. If your test matrix only covers Pixel devices because they are easier to emulate, you are missing the [majority of your Android audience](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one).

#### Where emulators fall short

Emulators are useful for initial checks but they do not reproduce OLED rendering, they do not replicate the behaviour of One UI or MIUI customisation layers, and they cannot show you how system fonts and accessibility settings interact with your dark mode styles. Real devices are necessary for at least part of the matrix, and the more varied the better.

#### Tablet and desktop web need separate attention

An iPad running Safari in dark mode has a different viewport, a different default font rendering, and a different system colour set than an iPhone running the same iOS version. Do not assume that iPhone testing covers iPad. Similarly, desktop web in dark mode needs to be tested at multiple viewport widths, because layout shifts that are invisible at mobile width can expose unstyled elements when the design stretches to fill a wider screen.

## UX/UI design built around *real* psychology

We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package.

[See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started)

No commitment

## Setting Up a Dark Mode Test Environment

The most practical starting point is to separate system-level dark mode from in-app dark mode. Some products implement their own dark mode toggle, which means the product's dark state can be triggered independently of the operating system setting. Others rely entirely on the `prefers-color-scheme` media query and inherit whatever the system is set to. Both approaches need different testing setups, and conflating them is how things get missed.

For system-level testing, set up a device profile for each operating system on your matrix with dark mode permanently enabled. Do not toggle it during the test session, because the goal is to see the product as a user who always runs dark mode sees it, not to catch transition behaviour. Create a separate profile for light mode, and a third for the moment of switching, because the transition itself can expose flash-of-incorrect-theme bugs that only appear during the change.

> A flash-of-incorrect-theme during the dark mode transition is one of the most jarring moments in a product experience.

For browser-based testing, Chrome DevTools has a `prefers-color-scheme` emulation toggle in the Rendering panel, which lets you test without changing your system setting. This is useful for rapid iteration but should not replace device testing, because DevTools emulation does not account for browser-specific stylesheet overrides or GPU-rendered colour differences.

Create a dedicated dark mode device profile on each physical test device with accessibility text size set to large. This catches layout breaks that only appear when dark mode and large text interact, which is a common real-world combination but a rare test configuration.

Document the exact OS version, browser version, and screen brightness level for each test session. Brightness level matters because dark mode contrast ratios that pass at full brightness can fail in low-light conditions, which is when most dark mode users are actually using the product.

## What to Test: Beyond Background and Text Colour

Background and text colour are the [first things a team checks](https://weareaffective.com/learning-centre/what-curiosity-looks-like-in-a-first-session-and-why-most-products-design-past-i) and often the last things they check thoroughly. The real failure points in dark mode are elsewhere. Images with transparent backgrounds are a common problem: a logo or icon with a transparent background that sits on a white canvas in light mode will appear to float on a dark surface in dark mode, which can make it invisible or visually broken depending on the image content.

Shadows and depth cues need particular attention. In light mode, a raised card uses a drop shadow against a light background to communicate elevation. In dark mode, that shadow becomes invisible against a dark background, and elevation must be communicated through a lighter surface colour instead. Products that carry their light-mode shadow system into dark mode without adjustment lose the entire visual hierarchy of the interface.

#### Interactive states and focus rings

Focus rings, hover states, and active states are frequently forgotten. A blue focus ring that reads clearly against a white background can disappear against a dark blue surface. WCAG 2.1 requires a contrast ratio of at least [4.5:1 for normal text and 3:1 for large text](https://www.w3.org/TR/WCAG21/), and those thresholds apply equally to interactive states in dark mode. Run a contrast check on every focusable element, not just body text.

#### Data visualisations and media

Charts, graphs, and maps are often hardcoded with colour values that assume a white background. A green line on a white chart is readable. That same green on a dark grey background may not meet contrast requirements, and the chart may have no dark mode variant. Video thumbnails, embedded maps, and third-party widgets are other areas where the host product has limited control but the user still experiences the result as part of your design.

Run your dark mode UI through a colour blindness simulator after checking standard contrast ratios. A palette that passes WCAG in dark mode can still be inaccessible to users with deuteranopia or protanopia, and low-light dark mode environments make colour discrimination harder for everyone.

## Dark Mode as a Trust Signal, Not Just a Visual Setting

On a healthcare product we designed for African markets, we made dark mode a deliberate trust decision rather than a preference feature. Users arriving at a health and insurance product often arrive in an [emotionally heightened state](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl), and a harsh, bright interface amplifies that anxiety rather than reducing it. We chose a dark UI with green undertones because green carries associations of calm, safety, and medical support without tipping into a clinical aesthetic that distances users from the product.

The language throughout that product was simplified and made very specific to further reduce stress, stripping out medical jargon at every turn. The dark UI and the language worked together: neither alone was enough. A calming colour palette with complex terminology would have left users feeling lost. Clear language on a bright, clinical interface would have felt cold. The combination was what produced a user experience that felt looked after rather than processed.

This matters for dark mode testing because colour choices do not operate in isolation. As a general principle, green tends toward calm, blue toward clinical authority, and red toward urgency and passion. Those associations do not disappear in dark mode, but they shift. A green that reads as calming on a white background can read as sickly or neon on a dark surface if the saturation is not adjusted for the new context. Testing dark mode without checking the [emotional register of the colour palette](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) is testing the wrong thing.

The [trust dimension extends to the quality](https://weareaffective.com/learning-centre/what-makes-users-trust-a-product-enough-to-enter-their-card-details) of the implementation. [Moldstud](https://moldstud.com/articles/p-the-influence-of-mobile-app-design-on-user-trust) reports that 75% of users judge credibility based on colour schemes. A dark mode that is inconsistent, patchy, or breaks on certain devices communicates that the product has not been finished, and that signals something about the care taken with everything else in the product too.

## How Colour Choices Shift in Dark Mode and What That Breaks

A colour system built for light mode is not simply inverted for dark mode, and this is one of the more underestimated challenges in [app UI design](https://weareaffective.com/app-ui-design). The relationship between hue, saturation, and perceived brightness changes significantly when the background goes dark. Colours that appear muted and harmonious on white can appear oversaturated and jarring on dark grey, because the contrast between the colour and its background has increased. Brand colours that have been approved in light mode will often need separate dark mode values, and those values need to be tested on actual screens rather than verified only in a design tool.

On the genetics product we worked on, we found that the design handoff process between intent and implementation introduced colour drift that was only visible on device. A wellness interface that used layered greens and whites in light mode needed a separate dark mode palette, and when the handoff went through an intermediary stage, the dark mode values arrived at development slightly adjusted from the original intent. The drift was subtle in Figma and visible on screen, and it only appeared on certain screen calibrations.

#### Primary, secondary, and semantic colours

Semantic colours are particularly vulnerable in dark mode. Red for errors, green for success, amber for warnings: these are often chosen with a light background assumption built in. In dark mode, the saturation levels that make these colours readable on white can tip into colours that feel aggressive or neon. A dark background requires less saturated, slightly lighter semantic colours to achieve the same emotional and functional read.

#### Testing against real content

Test dark mode against real content, not placeholder text and generic imagery. Real product photography often contains light backgrounds that create jarring boxes in dark interfaces. Real user-generated content can contain images that were never designed with dark mode in mind. The only way to find these issues is to load actual content into the dark mode test environment and scroll through it the way a real user would.

## Testing Dark Mode on Web Browsers

Browser testing for dark mode works across two axes: the browser itself, and the operating system it is running on. Chrome on macOS and Chrome on Windows both support dark mode, but the rendered output can differ because of how each OS passes colour information to the browser's rendering engine. Test both, and treat them as separate entries in your matrix.

In Chrome, the Rendering panel in DevTools gives you the `prefers-color-scheme` toggle and also a forced colours emulator for testing against Windows High Contrast mode. Firefox has a similar toggle in its DevTools. Safari on macOS respects the system dark mode setting and does not have an independent toggle, so testing Safari in dark mode requires the system setting to be enabled on the test machine.

#### Custom scrollbars and form elements

Custom scrollbar styles frequently break in dark mode because they are written with explicit light-mode colours and do not respond to the media query. Browser-native form elements like `select` dropdowns, date pickers, and file upload inputs inherit the browser's dark mode defaults unless explicitly overridden, and those defaults vary between Chrome, Firefox, and Safari. Check every form element in your product against each browser in dark mode, not just the ones your team styled.

#### Third-party embeds

Embedded content, including payment widgets, review carousels, chat tools, and map embeds, often has no dark mode support at all. The host page goes dark and the embedded widget stays light, creating a visible seam in the interface. Where the vendor does not offer a dark variant, the common solution is to wrap the embed in a light-mode container that preserves the embed's intended appearance as a deliberate design choice rather than an accidental inconsistency.

## Testing Dark Mode on iOS and Android

iOS dark mode is applied at the system level and propagates through native components automatically. Custom components built with UIKit or SwiftUI will generally adapt if they use semantic colours from the system colour set. Components built with hardcoded hex values will not adapt, and testing is the only way to find which components those are. Run the app in dark mode and tap through every screen, looking for elements that remain light when everything around them has shifted.

Android is more complex because the manufacturer layer matters as much as the Android version. A Samsung device running One UI generates its dark mode palette differently from a Google Pixel running stock Android, and MIUI on Xiaomi devices has its own interpretation again. The practical minimum is to test on one Samsung device and one stock Android device, because those two cover the widest range of Android dark mode behaviours.

#### Dynamic colour on Android 12 and later

Android 12 introduced Material You, which dynamically generates a colour palette from the user's wallpaper. If your app uses Material components and has not explicitly locked its colour values, the system can substitute wallpaper-derived colours into your UI. This means your brand palette can shift based on what image a user has chosen as their background. Test against several wallpapers with strongly different colours to see how much your UI is affected.

On Android, enable developer options and turn on "Show layout bounds" while in dark mode. This makes it easy to spot components that are not clipping correctly against dark backgrounds, which is a common problem with card shadows and bottom sheet overlays that were designed with a light background assumption.

## Testing Dark Mode on Desktop Operating Systems

macOS dark mode is handled consistently across Safari, Chrome, and Firefox, with the system setting propagating reliably. The main issues on macOS tend to be application-level rather than system-level: menu bars, tooltips, and modal overlays that use system components will adapt automatically, but any component using hardcoded colours will not. Electron-based apps and progressive web apps installed via Chrome are particular watch points because they interact with macOS dark mode through a web layer, not native APIs.

Windows is more complicated. Windows 10 and Windows 11 both have dark mode, but Windows 10's implementation is less complete and some system components remain light even when dark mode is enabled. Windows 11 is more consistent, but the accent colour system adds a variable that macOS does not have. The accent colour appears in scrollbars, toggle controls, progress bars, and selection highlights. If your product uses any of these components in their native state, test them against several different accent colour settings to see whether your UI remains coherent.

#### High contrast mode on Windows

Windows high contrast mode is not the same as dark mode, but some users enable both, and the interaction between them can be severe. High contrast mode overrides many CSS properties entirely, replacing your colours with system-defined high contrast values. Test your product in Windows high contrast mode separately from dark mode, and note which components collapse under high contrast. This is also an accessibility testing exercise: users who rely on high contrast mode are often users with low vision.

## Automating Dark Mode Checks in Your QA Pipeline

Automated dark mode testing covers a specific and useful part of the problem: visual regression. A visual regression tool takes a screenshot of each screen in dark mode, stores it as a baseline, and then flags any pixel-level differences in subsequent test runs. Tools like Percy, Chromatic, and Playwright's screenshot comparison feature all support this approach. The value is in catching unintended changes: a developer pushes a CSS change that inadvertently resets the dark mode colour on a particular component, and the visual regression test catches it before it ships.

Automation does not catch everything. [PCloudy](https://www.uxpin.com/studio/blog/checklist-for-manual-testing-of-react-components/) cites figures suggesting over 60% of accessibility issues are caught through manual testing rather than automated testing, and dark mode accessibility failures follow the same pattern. Contrast ratio checkers can be run automatically, but the judgement of whether a colour combination feels right, or whether a shadow system has lost its depth, requires a human eye. Automation handles the regression and the measurable checks. Manual testing handles the rest.

#### Setting up `prefers-color-scheme` in Playwright

Playwright allows you to set `colorScheme: 'dark'` in the browser context configuration, which means you can run your entire test suite in dark mode without changing any system settings. Pair this with screenshot comparison to build a dark mode regression suite that runs in CI. The setup is straightforward, and running it against your critical user journeys catches dark mode regressions as early as any other test type.

## Building a Dark Mode Test Checklist Your Team Will Actually Use

A checklist that covers everything is a checklist nobody uses. The goal is a checklist that covers the failure points most likely to appear on your specific product, in a format that takes under 30 minutes to run. Start by identifying the five screens your users spend the most time on, and build the checklist around those screens rather than the full product.

A practical dark mode checklist covers the following areas across each priority screen:

1. Text contrast against its background meets 4.5:1 for body text and 3:1 for large text.
2. All interactive states (hover, focus, active, disabled) are visible and distinguishable from one another.
3. Images with transparent backgrounds are rendering correctly against the dark surface.
4. Shadows and elevation cues are visible and communicating hierarchy correctly.
5. Semantic colours (errors, success, warnings) are readable and not appearing neon or washed out.
6. Third-party embeds and widgets are handled, either with a dark variant or a contained light-mode wrapper.
7. Form elements render consistently across the browsers in your test matrix.

Run this checklist at the [end of each sprint that touches styling](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one), and run it in full on each new device before a release. The checklist should live in the same place as your other QA documentation, not in a separate dark mode document that gets opened twice a year.

Assign one person per sprint to own dark mode review. A rotating responsibility with no named owner means the check either gets done twice or not at all. A named owner with the checklist and a set of test devices can complete a review in under half an hour.

## Conclusion

Dark mode is a parallel design system that sits alongside your light mode and requires the same level of ongoing testing. The platforms your users run on handle dark mode differently, the screen technologies they use render it differently, and the emotional register of your colour choices shifts when the background changes. All of that needs to be tested, not assumed.

The work we have done on products across healthcare, genetics, and wellness has shown consistently that the gap between a dark mode that looks right in design files and one that feels right on device is a testing gap. The healthcare product we designed for African markets worked because we tested the emotional and functional qualities of the dark UI against real conditions and real content, not because the design looked correct in isolation.

Build the test matrix, run the checklist, automate the regression checks, and assign clear ownership. Dark mode done well signals to users that the product has been finished properly, and that signal carries weight. Users who notice the quality of dark mode notice the quality of everything else too.

[Let's talk about your dark mode testing process](https://weareaffective.com/get-started) and where the gaps are most likely to be.

## Frequently Asked Questions

Why does dark mode look different on my Android device compared to my iPhone?

Android uses Material You on newer versions, which dynamically generates a colour palette from the user's wallpaper. This means your carefully chosen brand colours can shift into combinations you have never tested against, whereas iOS applies system-level colour overrides that interact with app-level styling in their own distinct way.

Why do colours look different on OLED screens compared to standard displays?

OLED and AMOLED screens render true black by switching pixels off entirely, so a very dark grey that looks sophisticated on an LCD panel can appear as a noticeable mismatch next to components that do hit true black. This distinction matters practically as well, because true black pixel usage on OLED displays can extend battery life by 30 to 60 percent.

Does dark mode behave differently across browsers on the same device?

Yes, Chrome, Safari, and Firefox each interpret the prefers-color-scheme query slightly differently and apply their own default stylesheets. Form elements such as inputs, dropdowns, and checkboxes are a particular problem, as they often inherit browser-level dark styling that overrides your own CSS unless you have written explicit rules to prevent it.

Why does dark mode cause issues on Windows that I never noticed when testing on a Mac?

Windows has its own high-contrast mode, a separate dark mode setting, and an accent colour system that Windows apps and Electron-based products inherit. If you only tested in Chrome on macOS, you would never have seen how that accent colour bleeds into scrollbars, toggles, and focus rings unless you explicitly overrode it.

What should I look for when testing dark mode beyond just background and text colour?

You should check that shadows remain visible, that images do not become muddy or invisible, and that contrast ratios hold up across different screen types. Component borders, form elements, and focus rings are also common areas where dark mode breaks in ways that are easy to miss during initial design reviews.

Is dark mode testing only relevant for native apps, or does it apply to websites too?

Dark mode testing applies equally to websites and web-based products, as browsers respond to the prefers-color-scheme media query and apply their own default styling on top of your CSS. A product built on a web wrapper can also inherit system-level accent colours from the operating system, making cross-platform testing just as important as it is for native applications.

Why is it not enough to just test dark mode in Figma or a single browser?

Figma shows you the design in isolation, without the influence of operating system overrides, browser stylesheets, or screen technology differences. Testing only in one browser on one machine means you are likely to miss issues that real users encounter daily across Android, Windows, OLED screens, and different browsers.

How can my team build a repeatable dark mode testing process?

The key is to treat dark mode as a testing discipline rather than a single design decision, with a structured checklist covering devices, operating systems, browsers, and screen types. Defining which platforms to prioritise and what to look for at each stage means your team can repeat the process consistently without rebuilding it from scratch each time.

## Related Articles

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.