Why dark mode flashes white — and how to stop it
Last updated: 20 August 2026 · By the Eclipse team. We solved this in our own extension, so the section on what a real fix costs is first-hand.
The short answer: the browser starts painting the page in its original light colours before your dark styles arrive. It is a race, not a setting you have missed — which is why it has been an open complaint against major dark mode extensions across Chrome, Firefox and Safari for years. A real fix requires the dark styles to be registered before the page runs, which forces a genuine architectural trade-off.
What is actually happening
A normal page load, in order:
- The browser receives the HTML and begins constructing the document.
- It applies the page’s own CSS — typically light.
- It paints the first frame. This is the white you see.
- The extension’s content script runs, analyses the page, generates dark styles, injects them.
- The browser repaints. The page goes dark.
The gap between steps 3 and 5 is the flash. On a fast machine and a light page it may be 20 milliseconds and barely register. On a heavy page, a cold cache, or a slow connection it can be several hundred milliseconds — long enough to be genuinely unpleasant in a dark room, which is exactly when you are using dark mode.
There is a second variant worth naming: the flash between pages. When you navigate, the browser can briefly show a blank canvas painted in the default background colour — white — before the next document renders at all. This one is not the extension’s fault in any meaningful sense; it is the browser’s inter-page paint.
Why it is hard to fix
The obvious answer — “run the extension earlier” — collides with what a good dark mode tool needs to do. Generating a proper theme requires reading the page’s stylesheets and computing replacement colours. You cannot read the page’s stylesheets before the page has loaded them. So the highest-quality theming is inherently late.
Extensions can ask to run at document_start, which is earlier, but a script running there still has to execute, and anything it needs to compute costs time before it can inject anything. Being early is not the same as being instant.
The real fix, and what it costs
Chrome exposes an API for registering content scripts and stylesheets ahead of time, so they are applied by the browser at document start without waiting for your code to run and decide. That closes the gap properly.
The catch: styles registered in advance have to exist in advance. You cannot register a theme you have not computed yet. So an extension that wants zero flash has to pre-generate stylesheets for its presets at build time and ship them as real files, then register those. The bespoke, fully analysed per-site theme still arrives afterwards — but by then the page is already dark, so the transition is dark-to-dark and invisible.
That is the approach Eclipse takes. Pre-generated CSS per preset, registered to persist across browser sessions and apply at document start, with the full analysis layered on after. We verify it rather than assert it: an automated test records frames during page load and fails the build if any light frame appears before the dark styles.
The trade-off is real and worth stating — pre-generated presets are less flexible than computing everything on the fly, and it constrains how theme settings can work at first paint. We think never flashing is worth that. Not everyone will agree.
Try it yourself: Eclipse applies a generated dark theme to any site, with per-site overrides and live brightness and contrast controls. Free, no account, no site limits.
What you can do with your current extension
These reduce the flash. None of them eliminates it.
- Set your browser and OS to dark. This changes the default background the browser paints between pages, which kills the inter-page white specifically. It is the single most effective thing you can do without switching tools.
- Use a dark new-tab page. Same reasoning.
- Switch to a filter mode if your extension has one. Filters apply more cheaply and can land sooner — at the cost of inverted photographs.
- Reduce other extensions. Content scripts queue; a heavy ad blocker running first delays everything behind it.
- Check for a “prevent flash” or early-injection option. Some extensions have one and do not enable it by default.
Not everything white is the extension
- Browser chrome and new tab page are governed by your browser theme, not by any extension.
- Sites with their own dark mode can flash their own light theme first if they read a saved preference in JavaScript after render. That is the site’s bug and no extension can fix it.
- PDF and internal browser pages are rendered by the browser’s own viewer, which extensions generally cannot restyle.
Related guides
Dark Reader Alternatives: An Honest Comparison
Dark Reader is the category leader and genuinely good. Here is where it struggles — measured, not asserted — and which alternative fits which problem.
How Dark Mode Extensions Actually Work
CSS filters, stylesheet rewriting, and generated themes are three different machines. Knowing which one you are running explains every quirk you have hit.
Dark Mode Not Working on Some Sites? 9 Causes
Shadow DOM, canvas, iframes, inline styles, CSP — the specific technical reasons a page resists dark mode, and which ones are actually fixable.
Is Dark Reader Slowing Down Your Browser?
Benchmarked slowdowns, why the cost grows over a browsing session, and how to tell a dark-mode extension apart from the other things making a tab sluggish.