“WordPress dark mode” turns out to mean at least five distinct things, built by different people solving different problems, with different amounts of the actual admin covered. Here’s what each option really does, where each one stops short, and which problem each one is actually solving.
WordPress core’s own admin color schemes
Every WordPress install already ships with this, no plugin required: Users → Profile → Admin Color Scheme, with built-in options like Midnight, Ectoplasm, and Ocean. It’s free, it’s already there, and it’s a real, native color scheme, not a hack.
It’s also the narrowest option on this list. As covered in why WordPress dark mode doesn’t cover the block editor, these built-in schemes style the admin bar and sidebar menu and stop there. The block editor’s writing canvas, the Classic Editor’s content area, and the Customizer’s control panel all stay in their default light appearance regardless of which built-in scheme is active, because none of them ever attempted to reach those surfaces in the first place.
OS-level or browser-level forced dark mode
Chrome has an experimental flag, “Auto Dark Mode for Web Contents,” that analyzes a page’s colors and inverts them to force a dark appearance on any site, wp-admin included, with no plugin or theme involvement at all. It’s a fundamentally different approach from everything else here: instead of loading a stylesheet someone wrote for this specific interface, it’s a runtime, algorithmic recoloring applied to whatever the browser happens to render.
The tradeoff shows up exactly where you’d expect from a generic, page-agnostic recoloring pass: it doesn’t know what it’s looking at. Chrome’s own documentation for the feature is upfront that it’s experimental, can change or be removed in any update, and can produce visual glitches like inverted images or unusual text colors on some pages. An admin dashboard full of icons, color-coded status indicators, and thumbnail previews is exactly the kind of dense, image-heavy interface where a blanket inversion pass is likely to get something visibly wrong.
Browser extensions like Dark Reader
Dark Reader and similar extensions take a more careful version of the same idea: analyze the page and recolor it intelligently, not just invert it, running as a browser extension rather than a Chrome flag. It works on wp-admin the same way it works on any other site, and it’s noticeably more capable than the OS-level version at guessing what should stay untouched.
The real limitation isn’t quality, it’s scope. An extension lives in one browser, on one device, tied to whoever installed it. It doesn’t apply to a colleague looking at the same dashboard from their own laptop, doesn’t survive switching to a different browser, and doesn’t travel with the WordPress site itself if someone logs in from a new machine. For a single person on one device who just wants their own dashboard dark, that’s a perfectly reasonable tradeoff. For a site with more than one admin, or an admin who moves between machines, it means reinstalling and reconfiguring the same extension everywhere, indefinitely.
Small third-party admin dark mode plugins
A handful of lightweight plugins exist specifically for this: BossAdmin, DarkPress, and Admin Dark Mode are three real examples currently listed on WordPress.org, each with a small number of active installs and a short, plain description along the lines of “change WordPress admin style into a dark color scheme.” None of their public descriptions mention the block editor canvas, the Classic Editor, or the Customizer specifically, which lines up with what “admin style” plugins built around a straightforward stylesheet swap would be expected to cover: the same chrome-only territory WordPress core’s own schemes already handle, just with different colors.
That’s not a criticism of the idea. It’s the natural result of the canvas being a separate iframe rather than part of the same document the rest of wp-admin lives in, the exact mechanism covered in why dark mode doesn’t cover the block editor. Reaching inside it takes a specific, separate technique, not just a bigger stylesheet.
A word about Night Eye
Night Eye shows up constantly in “WordPress dark mode plugin” searches, and it’s worth being clear about what it actually is: a dark mode toggle for your site’s visitors, not your admin dashboard. It adds a dark mode button to your public-facing pages so people reading your content can switch to a dark theme while they read. That’s a real, useful, different feature, aimed at a completely different audience than an admin trying to stop squinting at their own dashboard at 11pm. If the WordPress dark mode you’re after is for the people writing and managing the site rather than the people reading it, Night Eye is solving an adjacent problem, not this one.
Where Mawu Dark Mode fits
Mawu takes the same starting point as WordPress core’s own schemes, a real, native wp_admin_css_color() registration, so it shows up in the same picker as Midnight and Ectoplasm and respects per-user choice the same way. What’s different is everything past that starting point: the block editor canvas and Classic Editor content get their own dedicated CSS injected directly into their iframes, the Customizer’s control panel is treated as a second content root instead of an afterthought, and the rest of the dashboard is recolored per-element by a JavaScript engine that reads each element’s actual computed color rather than relying on a fixed list of selectors, so it holds up reasonably well against other plugins’ own admin screens too, not just core WordPress ones.
It’s free, with no separate paid tier gating any of that, and it’s wp-admin only: no frontend dark mode toggle for site visitors, which is a deliberate scope choice, not a missing feature. If what you actually want is Night Eye’s problem, that’s still the plugin for it.
See all 13 themes and the full feature list at Mawu Dark Mode, or what Mawu covers in wp-admin for the complete technical breakdown.