Learn how to design a useful Playwright cross-browser test matrix across Chromium, Firefox, WebKit, mobile viewports, and CI without making every pull request slow.
Learn the fastest way to make a full page screenshot in Chrome, plus better options for long pages, mobile captures, scheduled screenshots, and screenshot automation.
Learn what Puppeteer is, how it controls browsers, and how to use it for automation, testing, scraping, screenshots, PDFs, and performance workflows.
Developers, marketers, and founders use Allscreenshots to automate website captures. No credit card required to get started.
Dark mode screenshots are easy to miss in a manual review. Someone checks the homepage in the default theme, ships the change, and only later notices that a card, chart, icon, or empty state disappears against the dark background.
That is why dark mode needs to be part of the same repeatable screenshot workflow as desktop, mobile, and full-page captures. You should be able to capture the light and dark versions of a page from the same URL, with the same viewport, at the same point in the page lifecycle.
This guide explains how to capture dark mode screenshots reliably, what can go wrong, and how to add them to QA, documentation, and visual regression workflows.
A dark mode screenshot can mean one of three things:
| Method | How it works | Best for |
|---|---|---|
| System preference | The browser reports prefers-color-scheme: dark | Sites that follow the CSS media query |
| App theme setting | The app stores a theme choice in local storage, cookies, or user settings | Authenticated apps and dashboards |
| Forced CSS override | Custom CSS changes colors before capture | Narrow debugging or documentation work |
For public websites, the first method is usually enough. If the site uses CSS like this, the browser preference controls the theme:
@media (prefers-color-scheme: dark) {
:root {
color-scheme: dark;
--background: #08090a;
--foreground: #f8fafc;
}
}For web apps, the answer is often more complicated. A user may choose dark mode from an account menu, and the app may save that choice in local storage or on the server. In that case, a screenshot service cannot guess the intended theme from the URL alone. You need either a URL that opens the desired theme, a default that follows prefers-color-scheme, or an authenticated capture flow that starts from the right session state.
For sites that support the system preference, set darkMode to true in the screenshot request:
curl -X POST 'https://api.allscreenshots.com/v1/screenshots' \
-H 'X-API-Key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"url": "https://example.com",
"darkMode": true,
"fullPage": true,
"viewport": {
"width": 1440,
"height": 900
},
"responseType": "url"
}'This tells the browser to request the dark color scheme before the page renders. If the page responds to prefers-color-scheme: dark, the screenshot will use the dark theme.
Capture the light and dark versions from the same request code path. The fewer settings that differ, the easier it is to explain visual changes.
Most teams do not need only a dark screenshot. They need both themes, captured with identical settings.
const pages = [
'https://example.com/',
'https://example.com/pricing',
'https://example.com/docs'
];
for (const url of pages) {
for (const darkMode of [false, true]) {
const response = await fetch('https://api.allscreenshots.com/v1/screenshots', {
method: 'POST',
headers: {
'X-API-Key': process.env.SCREENSHOT_API_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({
url,
darkMode,
fullPage: true,
viewport: { width: 1440, height: 900 },
responseType: 'url'
})
});
const result = await response.json();
console.log(`${darkMode ? 'dark' : 'light'} ${url}: ${result.storageUrl}`);
}
}Use a predictable filename if you store the images:
homepage-light-desktop.png
homepage-dark-desktop.png
pricing-light-desktop.png
pricing-dark-desktop.png
docs-light-desktop.png
docs-dark-desktop.pngThat naming pattern matters later when screenshots become review artifacts, release evidence, or visual regression baselines.
Theme bugs often show up differently on mobile. A desktop navigation bar may be fine, while the mobile drawer has a dark background with dark links.
Capture both themes at the viewport sizes you actually care about:
{
"url": "https://example.com/pricing",
"darkMode": true,
"fullPage": true,
"viewport": {
"width": 390,
"height": 844
},
"responseType": "url"
}For many marketing sites, two desktop screenshots and two mobile screenshots are enough:
| Theme | Viewport | Use it for |
|---|---|---|
| Light | 1440 x 900 | Default desktop review |
| Dark | 1440 x 900 | Dark desktop review |
| Light | 390 x 844 | Mobile navigation and responsive layout |
| Dark | 390 x 844 | Dark mobile navigation and forms |
Do not start with ten device sizes unless you have a real reason. A small, consistent matrix is more likely to run on every release.
Dark mode bugs can be timing bugs. A page may render in light mode, then switch to dark after client-side JavaScript loads the saved theme. If you capture too early, you get the wrong state.
Prefer a stable selector that appears after the app has applied its theme:
{
"url": "https://example.com/dashboard",
"darkMode": true,
"waitForSelector": "[data-theme-ready='true']",
"viewport": {
"width": 1440,
"height": 900
},
"responseType": "url"
}If you own the app, adding a readiness marker is worth it. It makes screenshots faster and less flaky than waiting for a fixed delay.
<main data-theme-ready="true">
...
</main>Use delay only when the visual state really needs a short settle time, such as chart animations or font swaps:
{
"url": "https://example.com/reports",
"darkMode": true,
"waitForSelector": "#revenue-chart",
"delay": 500,
"responseType": "url"
}Dark mode review is not only about background color. Look for the details that usually break:
Screenshots are useful because many of these issues are obvious visually but hard to catch with unit tests.
If your site has a real dark theme, keep separate baselines for light and dark mode. Do not compare a dark screenshot against a light baseline or try to normalize colors afterward.
A practical baseline layout:
baselines/
light/
desktop/
homepage.png
pricing.png
mobile/
homepage.png
pricing.png
dark/
desktop/
homepage.png
pricing.png
mobile/
homepage.png
pricing.pngThen your comparison code can choose the baseline from the same dimensions that produced the screenshot: page, theme, viewport, and format.
For a broader workflow, pair this with the visual regression testing guide and GitHub Actions screenshot testing.
The page may not support prefers-color-scheme, or the app may override the browser preference with its own saved theme. Check whether dark mode works in a normal browser when the system preference is dark.
The app probably applies the theme after hydration. Add a theme-ready selector and wait for it before capture.
This usually means the page mixes hard-coded colors with theme variables. Screenshots are a good way to find the exact components that still need tokens.
Website screenshots capture the page, not the Chrome toolbar, tab strip, or operating system frame. That is normally what you want for QA and automation.
Start with the pages that represent the product:
Capture each page in light and dark mode at desktop width. Add mobile once the desktop set is useful. Review the images before major releases, attach them to pull requests, or compare them automatically in CI.
The important part is consistency. Dark mode screenshots only become useful when they are captured the same way every time.