Dark Mode Reading on the Web: When It Helps and When It Hurts

Dark mode reading gets recommended the way standing desks once did: as a single change that fixes tired eyes. Then it goes on, and after a week the eyes are still tired, some text looks slightly blurred, and a few sites have become harder to use rather than easier. The honest version is narrower and more useful. Negative polarity helps some people in some conditions for some tasks, and the conditions matter more than the mode.

The research does not say what the recommendation says

Nielsen Norman Group reviewed the academic literature on contrast polarity and summarized the result in two sentences.

In people with normal vision (or corrected-to-normal vision), visual performance tends to be better with light mode, whereas some people with cataract and related disorders may perform better with dark mode. On the flip side, long-term reading in light mode may be associated with myopia. Source: nngroup.com

The mechanism behind the first half is the pupil. Bright surroundings make the pupil contract, a smaller aperture reduces spherical aberration and increases depth of field, and text is therefore easier to hold in focus. A dark screen in a dark room does the opposite: the pupil opens, the aperture widens, and the optical system has more work to do to keep edges sharp. That is the same principle as a camera lens at f/2.8 against the same lens at f/16.

This is why the advice splits along individual eyes rather than along taste. Readers with clouded lenses, where scattered light inside the eye is the limiting factor, often do better with less light coming at them. Readers with uncorrected astigmatism frequently report the opposite of comfort in dark mode, because light text on a dark background spreads at the edges and that bloom lands on an already imprecise focus.

Two conclusions follow. Dark mode is not a health measure, and light mode is not negligence. Both are legitimate settings whose value depends on the eye in front of the screen and the room around it.

Contrast is a number, and both directions fail

The mode question hides a more measurable one. The Web Content Accessibility Guidelines set a floor for text: a contrast ratio of at least 4.5 to 1 against its background, or 3 to 1 for large scale text. That floor exists because reduced contrast sensitivity is common and gets worse with age, and it applies to dark palettes exactly as it applies to light ones.

Dark themes fail that floor in a particular way. Mid grey text on a dark grey panel looks tasteful in a screenshot and drops below the threshold in practice, which is why secondary text, placeholder text and disabled labels are the first things to become unreadable in a badly built dark theme. The reference material on the criterion is published openly at w3.org, and a contrast checker settles the question in seconds for any specific pair of colors.

The opposite failure is less obvious. Pure white text on pure black is the maximum available contrast and is often uncomfortable for continuous reading, because the bright glyphs appear to bleed into the black around them. Halation is the usual name for the effect, and it is the reason most careful dark themes use an off black background and a slightly dimmed foreground rather than the extremes. Apple, GitHub and most mature design systems all land in that region.

The practical implication is that the quality of a dark theme matters more than the choice of dark mode. A well built light theme beats a badly built dark one for reading, every time, regardless of preference.

The room usually decides

Ambient light is the variable most often left out of the discussion, and it outweighs the software setting.

A screen in a bright room is competing with the room. A light page in that setting roughly matches the surroundings, so the eye is not repeatedly re-adapting between page and desk. A dark page in the same room becomes a dim rectangle inside a bright field, and every glance away and back forces an adjustment.

At night in a dim room the relationship reverses. A white page becomes a lamp pointed at the reader, and even at low brightness the mismatch between page and room is large.

Screen brightness is the third term, and it is the one worth touching first. A light page at a brightness tuned to the room is more comfortable than a dark page at a brightness left where it was in the afternoon. Anyone reaching for dark mode because the screen is too bright at night has identified the right symptom and the wrong control.

macOS provides the setting that connects these. System Settings, Appearance, offers Light, Dark and Auto, where Auto follows the time of day. Apple's documentation notes that Auto will not switch until the Mac has been idle for at least a minute, so a mode change in the middle of a work session waits for a pause rather than interrupting it. For readers whose day genuinely spans a bright office and a dim evening, Auto is a closer fit than picking one mode and defending it.

The task matters as much as the eye

Reading is not one activity, and the polarity that suits one kind does not suit the others.

What is on screen	Which polarity tends to work	Why
Long prose, a single column of text	Either, if contrast is tuned	Nothing depends on color, so comfort decides
Proofreading and copy editing	Light	Matches the medium the text will be read in later, and typographic detail is easier to see
Code and logs	Dark	Syntax highlighting was designed for dark backgrounds and hue differences read clearly
Dashboards and spreadsheets	The app's own theme	Color carries meaning, so any automatic inversion risks changing it
Photographs and design work	Light	Judging color against a dark surround shifts perception of the image
Scanning a list of messages	Either	Layout and density matter far more than polarity

The pattern in that table is the useful part. Where color carries information, the safe answer is whatever theme the people who built the app designed and tested. Where the screen is text on a background, comfort can decide freely.

This is also why a single global switch is a poor fit for a working day. A person who writes in the morning, reviews design at midday and reads documentation at night has three different correct answers, and no system wide preference can hold all three.

What tools can change, and what they cannot

Three mechanisms exist, and only one of them produces a palette anybody actually designed.

The first is a site's own dark theme, chosen by the people who built the interface and tested against their own colors. Gmail has one under Settings, in the Theme section. Google Drive has one on the web under Settings, in the Appearance section, with Light, Dark and Device default. Many web apps now follow the operating system automatically through the prefers-color-scheme media query, which is why some sites turn dark on a Mac with no extension involved.

The second is browser level inversion, either through a Chromium flag or through an extension that rewrites colors on the fly. This reaches sites that have no dark theme at all, at the cost of guessing. Extensions in this class need permission to read and change page content, and the better ones hold per site rules so that the guess can be turned off where it fails.

The third is reader mode, which strips a page down to text and applies its own typography and background. For long articles this often beats both of the others, because it also fixes line length and font size, and those two variables affect reading comfort at least as much as polarity does.

None of the three can improve a badly built page. Twelve pixel grey text in a 1,200 pixel wide column is uncomfortable in any polarity, and darkening it changes nothing about the two reasons it is uncomfortable.

The variables that outrank polarity

When reading on screen is uncomfortable, polarity is rarely the largest term in the equation. Four others usually matter more, and all four are adjustable.

Line length comes first. A column that runs the full width of a large display forces the eye to travel a long way and then find the start of the next line, and losing the line is the most common cause of re-reading. Somewhere between 50 and 75 characters per line is the range typography has settled on for continuous text. On a wide Mac display, narrowing the window is a more effective change than any color adjustment, and it takes one drag.

Font size comes second. Browser zoom at 110 or 125 percent on a text heavy site costs nothing and removes a large amount of strain. Chrome, Safari and Firefox all remember the level per site, so the adjustment is made once.

Session length comes third. Continuous close focus reduces blink rate, and a dry eye reads worse than a tired one. Looking at something distant for a few seconds every twenty minutes is the standard advice, and it addresses a cause that no palette touches.

Display scaling comes fourth. A Mac running a scaled resolution renders text slightly softer than at its native setting, and that softness reads as eye strain without ever looking like a settings problem. Checking the display setting is worth one minute before concluding that a theme is at fault.

None of these are arguments against dark mode. They are the reason a dark theme sometimes gets credit that belongs elsewhere, and the reason it sometimes gets blamed for discomfort it did not cause.

Setting it per app instead of per system

Once the answer differs by task, the setting has to live closer to the task. That is easier when each web app is a window of its own rather than a tab in a pile, because a window can hold its own appearance and keep it.

A browser that keeps each web app in its own window makes the per app choice the normal case: the writing tool in its own theme, the code review tool in a dark one, the design tool in whatever the designers intended. Grouping those windows into workspaces adds a second useful property, which is that an evening reading context can look different from a daytime working context without anything being reconfigured. For readers who spend most of the day inside three or four services, checking which of those have a native dark theme in the list of supported apps is a faster route to comfort than any global inversion.

The point is not that dark mode is wrong. It is that a per app setting produces a palette someone designed, and a global override produces a palette a filter guessed.

What to change first

Set screen brightness to match the room, then turn on the native dark theme inside the two or three web apps where most reading happens and leave everything else alone for a week. If the eyes are still tired after that, the variable to examine next is font size and line length, not polarity. A browser that lets each app hold its own appearance is what makes that per app approach practical, and SpaceDeck is built on it.