Dark mode not working on some sites? 9 causes
Last updated: 20 August 2026 · By the Eclipse team.
The short answer: most of the time it is not a bug. Some content genuinely cannot be restyled from outside — pixels drawn into a <canvas>, cross-origin iframes the browser deliberately walls off, and encapsulated components — and no extension of any quality can reach them. The list below separates what is fixable from what is a hard boundary, so you stop troubleshooting the ones that have no fix.
Start here: three quick checks
- Is the extension enabled for this site? Most have a per-site toggle that is easy to hit by accident.
- Does the site have its own dark mode? Good extensions defer to it. What looks like a failure may be the site’s own theme.
- Hard reload with Ctrl+Shift+R (Cmd+Shift+R on Mac). Cached stylesheets are a real cause.
1. Content drawn in a canvas
A <canvas> element is a bitmap the page draws into with JavaScript. There is no CSS describing what is inside it — the colours are pixels, not declarations. Charts, maps, games, diagram tools and some document viewers use it.
Fixable: no, not without inverting the whole element and wrecking it. Many sites with canvas widgets offer their own dark theme for exactly this reason.
2. Cross-origin iframes
An embedded frame from another domain is isolated by the browser’s same-origin policy. The outer page — and anything acting on it — cannot reach inside to restyle it. Comment widgets, embedded videos, payment forms, maps and support chat boxes are typically iframes.
Fixable: only if the extension has permission for the embedded domain too and injects there independently. That is why one white rectangle often survives on an otherwise dark page.
3. Shadow DOM encapsulation
Web components can attach a closed shadow root, which deliberately hides their internals from outside JavaScript and stylesheets. That is the feature working as designed.
Fixable: open shadow roots can often be handled; closed ones cannot.
4. Colours baked into images
A logo or UI element exported as a PNG with a white background carries that white as image data. Restyling cannot change it, and darkening it would also darken any photograph — which is the behaviour you do not want.
Fixable: not properly. Some tools special-case small images, which helps with logos and harms photos.
5. Inline styles and runtime-injected CSS
Colours set directly on elements by JavaScript, or injected as new style rules after load, arrive after the initial analysis. A well-built extension watches for these and reprocesses — but there is a window, and heavy single-page apps can produce a lot of it.
Fixable: yes, mostly, and it is one of the clearest quality differences between tools.
6. Content Security Policy
A strict CSP can restrict style injection. Extensions have elevated privileges that get around most of this, but tightly locked-down sites — banking, enterprise dashboards — can still interfere.
Fixable: sometimes, and rarely worth pursuing.
7. Browser internal pages and PDFs
Extensions cannot inject into chrome:// pages, the Web Store, or the built-in PDF viewer. This is a hard security boundary.
Fixable: no. Chrome has its own PDF dark setting; check there instead.
8. The site detects and resists
A minority of sites actively fight modification, or re-apply their own colours on a timer. The result can be flickering between light and dark.
Fixable: usually only by excluding the site.
9. It is working, and it looks wrong
Sometimes dark mode applied perfectly and the outcome is simply poor — muddy greys, low-contrast text, an odd accent colour. That is a contrast and colour-model problem, not a coverage problem, and it usually responds to a brightness or contrast adjustment.
Quick diagnosis
| What you see | Most likely cause | Fixable? |
|---|---|---|
| One white rectangle in the page | Cross-origin iframe | Sometimes |
| Chart or map stays light | Canvas | No |
| Whole page unaffected | Site excluded, or extension off | Yes |
| Flickers light and dark | Site re-applying its own styles | Rarely |
| Works, then breaks after scrolling | Runtime-injected styles | Yes |
| Logos on white blocks | Baked-in image background | No |
| Text hard to read | Contrast model | Yes — adjust settings |
What to actually do
- Prefer the site’s own dark mode where it exists. It will always beat a generated one.
- Exclude sites that fight. Per-site overrides exist for this.
- Adjust rather than abandon when the issue is readability rather than coverage.
- Try a different mode if your extension offers several — a filter reaches some things a generated theme cannot, at a cost.
Eclipse keeps per-site settings with no cap on how many sites you configure, defers to a site’s own dark theme when one is present, and exposes live brightness, contrast and saturation controls for the cases where coverage is fine but the result needs tuning.
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.
Related guides
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 Contrast Done Right: APCA vs WCAG
WCAG’s 4.5:1 ratio was built for dark-on-light and misjudges light-on-dark. Why perceptual contrast models exist and what they change.
Why Dark Mode Flashes White — and How to Stop It
That stab of white between page loads is a race condition, not a bug in your eyes. What causes it, why it is hard to fix, and what a fix requires.
Dark Mode for Sites That Don’t Offer It
Which major sites ship a real dark theme, which ship a partial one, and what to do about the long tail that never will.