Dark Reader on a Mac: turning bright web apps down for long sessions

Dark Reader gets recommended as a reading tool, and for an article that is the whole story. Install it, the page goes dark, the eyes stop straining. The people who end up dissatisfied with it are usually the ones who spend the day inside web apps instead of articles. Eight hours in a mail client, a ticket queue, a spreadsheet, and an admin dashboard is a different problem, because those screens are not text on a background. They are colour used as information.

The extension is free on Chrome, Firefox, and Edge, open source under the MIT licence, and has been in development since 2014, with the project's own site stating it is trusted by ten million users and sends no user data anywhere. None of that is in dispute. The question worth working through is which parts of an all-day workflow it should be pointed at, and which parts it should be told to leave alone.

An interface is not an article

An article has one job: present text. Inverting the background and lightening the text preserves everything that matters, and if a photograph comes out slightly dull, nothing was lost.

An application interface uses colour to carry state. Red means failure, green means passing, amber means pending. A chart's series are distinguished only by hue. A diff is readable only because additions and removals are tinted differently. A calendar is legible because each project has a colour. Syntax highlighting is colour by definition.

A generic darkening layer cannot know which of those colours is decorative and which is load-bearing. It maps the whole palette, and the result is often still readable but no longer scannable. The failure is quiet, which is what makes it expensive: nothing looks broken, the information simply takes longer to find, and that cost lands on every glance for the rest of the day.

The useful posture is to treat forced darkening as the fallback, not the default. Where an app already ships a dark appearance of its own, that version was built by people who knew which colours meant something. Checking each app's own appearance setting before forcing anything is a five minute pass that removes most of the trouble in advance.

The exclusion list is the actual configuration

Most of the value in this extension sits in a screen people never open. Its documentation describes two opposite operating modes on the site list:

Use Invert listed only if you wish Dark Reader to work only on listed websites. Not invert listed will prevent the extension from working on listed websites. Source: darkreader.org

For someone living in a handful of web apps, Invert listed only is usually the better starting point, because it inverts the relationship. Instead of darkening everything and then chasing exceptions, nothing is touched until it is named. The list of things worth darkening in a working day tends to be short, and the list of things that must stay untouched is long and impossible to predict.

The patterns it accepts are more precise than most people use. The documentation gives forms such as google.com, mail.google.com, google.*, and google.com/maps, and regular expressions are supported when they start and end with a slash. That path-level granularity matters in an app, where a settings page might darken cleanly while a reporting page does not.

One habit makes the list stay correct over time. Web apps are redesigned without warning, and a page that darkened cleanly in March can break in June when the vendor ships a new component library. Reviewing the list once a quarter, rather than adding to it forever, keeps the exceptions tied to the current version of each app instead of to a version that no longer exists.

There is a per-site intensity control as well. The Only for button binds the current brightness, contrast, sepia, and saturation values to the site being viewed, so a dashboard with pale grey lines can be pushed harder than a mail client without changing the global setting. One button click, then adjust, then click again to cancel. The toggle at the top of the popup adds or removes the current site from the list, which makes building the list a matter of browsing rather than typing.

Choosing a mode by what the app is made of

Four theme generation modes ship with the extension, and the trade-off between them is documented rather than left to guesswork. Dynamic analyses stylesheets, background images, and vector graphics, which produces the best result and costs time on first load. Filter inverts the whole page with a CSS filter and reverts parts of it. Filter+ does the same with custom SVG filters and handles colour better. Static generates a basic stylesheet quickly.

For interfaces, the documented side effects of the filter approaches are the deciding factor. Filter mode disables text sub-pixel rendering, inverts already dark parts back into light, and causes lag on large pages. An app that is already partly dark is precisely the case where that inversion produces the worst result, and a long table is precisely the page where the lag shows up.

Situation	Reasonable first choice	Reason
Text-heavy app, mostly light already	Dynamic	Best visual result, cost is paid on load
Very large tables or long lists	Static	Fast to generate, least work per page
App already partly dark	Leave it excluded	Filter modes invert dark parts back to light
Images and charts must stay accurate	Exclude, or use the app's own theme	No mode can tell decoration from meaning

What stays bright regardless

Several surfaces are outside any extension's reach, and knowing which ones saves time spent hunting for a setting that does not exist. The extension's own documentation is direct about it: the extensions store page and settings pages remain white because the extension has no access to them, and the new tab page and browser theme are controlled by the browser's own settings rather than by the extension.

The same section explains the white flash people report when opening a new tab or following a link. Before a page loads, the browser paints its own theme background colour, so the fix is a dark theme in the browser rather than anything in the extension. On a Mac with the system appearance set to dark, that is usually already in place, which is why the flash is more common on systems left in light appearance.

Two more cases have documented switches rather than being limitations. Private windows require the extension to be allowed in incognito on the chrome://extensions page, and local files require Allow access to file URLs on the same page. If the popup's toggle button appears greyed out, the documentation attributes it to the browser restricting script injection into that particular page, which is not something a setting can override.

Access is also worth being explicit about, since this is a tool that reads and rewrites every page it is pointed at. The project states that the permissions exist to analyse and modify a site's appearance, that no ads are inserted, and that no data is collected or sent anywhere. For anyone whose browser holds a production admin console, that declaration, the MIT licence, and the public source are the three things to weigh rather than the star rating.

Make the toggle cheap, and the rest follows

A darkening layer that is awkward to turn off gets left on over pages where it is doing damage. Making the switch cost nothing is therefore a real setting rather than a nicety, and three parts of the interface exist for it.

The popup itself carries two separate controls that are easy to confuse. The on and off switch disables the extension everywhere. The toggle site button adds the current site to the ignore list or removes it from there. During the first week those two get pressed interchangeably, which produces the impression that settings are not sticking. The first is a global kill switch, the second is a per-site decision that persists.

Underneath those buttons sit links for editing the hotkeys, which is where the cost of toggling actually drops. A key assigned to the site toggle turns the decision into a reflex: land on a dashboard where the colours went wrong, press the key, carry on. Without it, every exception costs a click on the toolbar and a second click in the popup, and exceptions stop getting made.

Getting to the popup at all is worth one setup step. The documentation notes that if the icon is hidden after installation, it is reached by clicking the Extensions button next to the address bar and then the button next to Dark Reader, which pins it to the toolbar.

The More tab holds two adjustments that matter specifically in interfaces rather than articles. A font can be substituted across pages, and the text stroke can be thickened. Light text on a dark background reads thinner than the reverse, and dense application text is where that thinning is most noticeable, so a small stroke increase often does more for legibility than raising the contrast slider. For anyone willing to go further, the popup also opens a configuration editor for the current theme mode, which accepts CSS selectors for fixing one stubborn site.

Where the browser is the wrong place for the setting

Across Chrome, Firefox, and Edge the extension is free. On Safari it is a separate App Store app from Dark Reader Ltd, priced at 4.99 US dollars, currently at version 1.5.10. That split is worth knowing for anyone who keeps Safari for one or two services.

The deeper structural point is that an extension's settings belong to a browser profile, not to an app. One cookie jar, one set of extension settings, one appearance policy for everything inside it. Someone running two accounts of the same service cannot give one a dark theme and the other a light one, because as far as the browser is concerned they are the same site.

Giving each service its own window changes where the setting lives. The Workspaces model keeps each web app in a separate container, and a per-app stylesheet can then be attached to exactly one of them and reapplied on every load, which is what the Features page describes as Boost. That is a narrower instrument than a general darkening engine: instead of remapping an entire palette, it changes the specific surfaces that are too bright while leaving the colours that carry meaning untouched. Anyone weighing that approach against the alternatives can start from Compared with Shift.

What to change first

Switch the site list to Invert listed only, add nothing, and spend a day noting which screens genuinely hurt to look at. Enable each app's own dark appearance before forcing anything, and for the ones that remain, add them to the list individually with per-site values rather than raising the global setting. For services that are open all day, a window with its own stylesheet, such as the one SpaceDeck provides, is a steadier fix than a browser-wide filter.