How to Test Dark Mode Across Browsers

What Is Dark Mode Testing, and Why Does It Break Across Browsers?

Dark mode testing is the practice of checking how your website looks and behaves when the user's operating system or browser is set to a dark color scheme. The browser exposes that preference through the prefers-color-scheme media feature, and your CSS responds with a darker palette.

The problem is that a dark stylesheet is not applied identically everywhere. Chromium, WebKit (Safari), and Gecko (Firefox) each render native form controls, system colors, scrollbars, and images in their own way once dark mode is active.

That is the same engine gap behind broader cross browser compatibility problems.

So a theme that reads perfectly in Chrome on Windows can surface unreadable inputs in Safari, or a hard-coded shadow that disappears on a dark background in Firefox. If you already style with CSS media queries, dark mode testing is how you confirm your dark rules hold up across every engine your users are on.

What Breaks in Dark Mode From One Browser to the Next?

Most dark mode bugs are not about the color palette itself. They come from elements that ignore your theme, or that the browser restyles on its own. These are the failure modes worth checking on every engine.

The last row is the one teams miss most. Dark mode and forced-colors are separate features: a site can pass a dark theme review and still break under Windows High Contrast, which actively replaces your colors rather than just signaling a dark preference.

Contrast is the thread running through all of it. Once the background flips dark, text and icons that were fine on white can drop below readable levels, which is why a dark theme pass pairs naturally with checking accessible color contrast.

How Do You Test Dark Mode in a Live Session?

The fastest hands-on check is a mobile session with dark mode switched on. TestMu AI has a Dark Mode toggle on both its virtual mobile sessions and its real devices, so you flip the theme in the cloud without changing any system settings.

On the virtual side, the iOS simulator renders in real WebKit, so Safari-specific dark styling shows up accurately without owning any hardware.

In a live testing session, the Dark Mode toggle sits in the session Settings:

• Start a live mobile session. Pick a mobile browser on a virtual device, such as Chrome on an Android emulator or Safari on an iOS simulator, and load your URL.
• Turn on Dark Mode. Open Settings in the session controls and toggle Dark Mode on, then reload the page so it takes full effect.
• Walk each surface. Check inputs, dropdowns, images, icons, shadows, and modals against the failure list above.
• Repeat across engines. Cover Chrome, Safari, and the other browsers your audience uses, so a theme that holds in one engine cannot fail silently in another.

The same Dark Mode toggle is on the real device cloud too, from Device Control on real iOS and Android devices, so dark mode folds into a physical-hardware pass whenever your release process calls for one.

On desktop there is no in-session toggle, so dark mode follows the operating system appearance and is quickest to force through automation, which is covered next. For the manual toggle, see the docs on enabling dark mode on real devices.

How Do You Automate Dark Mode Tests Across Browsers?

Once you know the theme is right, automation keeps it right on every build. Both Playwright and Selenium can force a dark color scheme, so you never depend on the machine's actual system setting.

In Playwright, set the color scheme on the browser context and run it against the TestMu AI cloud grid:

const { chromium } = require('playwright');

const capabilities = {
  browserName: 'Chrome',
  browserVersion: 'latest',
  'LT:Options': {
    platform: 'Windows 11',
    build: 'Dark Mode Cross Browser Test',
    name: 'prefers-color-scheme: dark',
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,
  },
};

(async () => {
  const browser = await chromium.connect(
    `wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(JSON.stringify(capabilities))}`
  );
  // Force dark mode for the whole context
  const context = await browser.newContext({ colorScheme: 'dark' });
  const page = await context.newPage();
  await page.goto('https://www.testmuai.com/selenium-playground/');
  await page.screenshot({ path: 'dark-mode.png' });
  await browser.close();
})();

In Selenium, force the preference through the Chrome DevTools Protocol before you navigate:

# Chromium engines: emulate prefers-color-scheme via CDP
driver.execute_cdp_cmd('Emulation.setEmulatedMedia', {
    'features': [{'name': 'prefers-color-scheme', 'value': 'dark'}]
})
driver.get('https://www.testmuai.com/selenium-playground/')

One honest limit: this CDP emulation only covers Chromium browsers. For real Safari (WebKit) and Firefox (Gecko) dark mode, run the suite on real browsers through the automation cloud, which spans 3,000+ browser and OS combinations so the same test executes on the engines emulation cannot fake.

If your page branches its own behavior on the theme, read the preference directly in JavaScript with matchMedia, which is also handy for swapping assets or logging what users actually get:

// Detect the user's dark mode preference in JavaScript
const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;

// React to changes while the page is open
window.matchMedia('(prefers-color-scheme: dark)')
  .addEventListener('change', (event) => {
    console.log('dark mode is now', event.matches);
  });

Once the theme renders correctly, lock it in with visual regression testing: capture the light and dark version of each page and diff them, so a later style change cannot quietly break the dark theme.

Can You Test Dark Mode With AI?

Writing a selector-based assertion for a dark theme is fiddly, because you are checking computed colors rather than text. This is where an AI-native approach helps.

With Kane AI by TestMu AI, you describe the check in plain language, such as "toggle dark mode and assert the background turns dark," and it drives the session and validates the result for you. The intent stays readable even when the underlying palette changes.

That keeps a dark mode test resilient: you are asserting the behavior a user cares about, not a brittle hex value that a design refresh will break next quarter.

Dark Mode Cross-Browser Testing Checklist

Run this before you ship a dark theme, on every engine your audience uses.

• prefers-color-scheme is honored, with a sensible fallback where it is unsupported.
• Native inputs, checkboxes, and dropdowns stay readable, checked on Safari and iOS.
• Transparent and white-background images and logos remain visible on the dark canvas.
• SVG and icon-font glyphs inherit currentColor instead of a hard-coded fill.
• Shadows, borders, and dividers are still visible against dark surfaces.
• Text and icon contrast meets accessibility targets once the background flips.
• forced-colors and Windows High Contrast are tested separately from dark mode.
• Any in-page dark mode toggle persists across reloads and matches the system setting.

Ship Dark Mode Where Your Users Actually See It

Dark mode is a real user setting, and the bugs it creates only appear once you flip the switch on the exact browser and OS your audience uses. A theme that passes in Chrome tells you nothing about Safari, iOS, or Windows High Contrast.

Check it in a live session first, lock it in with automation across engines, and let AI keep the assertions readable as the design evolves. See the docs on real-time browser testing to run your first dark mode pass across real browsers.