Skip to content

Light & Dark Themes — What the Research Actually Says, and How SageOx Ships It

Durable, reference-backed guidance for how SageOx serves light and dark mode, and what to put in a dark theme so it's comfortable rather than just cool. The decision and rationale live in DDR-008; this is the scannable working reference.

One-line takeaway: The developer dark-mode preference optimizes how taxing the day feels over a long, often after-hours session in a dim room — not reading speed. Light mode is more legible; dark mode is less costly to inhabit in the conditions developers actually keep. Both are true, on different axes. So we ship both, respect the OS, default by surface type, and tone the dark theme with discipline (near-black not pure black, off-white not pure white, desaturate, lighten to elevate).

What the 2024–2026 research actually found

The popular "dark mode is objectively easier on your eyes" claim is not supported by the evidence — the strongest findings point the other way, and most of the rest say "it depends."

Finding Direction Source
Positive polarity (light mode) is measurably better for reading & proofreading — higher luminance constricts the pupil, sharpens the retinal image; biggest win at small character sizes (i.e. code) Light ▲ Piepenbrock, Mayr & Buchner — Ergonomics 2013, Human Factors 2014
Reading speed can drop up to ~26% on negative polarity (dark mode) for normal-vision readers Light ▲ Aggregated in Superhuman 2026 research review
Cognitive scores higher in light mode (n=173; varies by age/education) Light ▲ "The dark side of the interface," Ergonomics 2025
No significant difference in overall visual fatigue between modes (2025 clinical, tablets) Tie MDPI / IJERPH 2025
Dark theme more accurate on hard / medium-complexity tasks (but higher cognitive workload) Dark ▲ Eye-tracking, ETRA 2025
Dark reduces glare in dim/night settings; nighttime favors light only for sustained reading Dark ▲ (context) While & Sarvghad 2024
Preference splits in even thirds — dark-only / light-only / switch-by-context Split NN/g — Dark vs Light Mode
~47–50% of adults with astigmatism get halation (bleed/halo) from high-contrast text on dark Dark ▼ (a11y) NN/g, Level Access
No scientific consensus dark mode improves cognition — Systematic review (per Superhuman 2026)
OLED battery saving is real (14–67% display power; ~25% on 2024 OLED laptops); negligible on LCD Dark ▲ (battery) Superhuman 2026

"Reading speed drops up to ~26% on negative polarity for normal vision" — in plain terms: negative polarity = light text on a dark background (dark mode); positive polarity = dark text on light (light mode); normal vision = people without low-vision or light-sensitivity conditions (the majority). Across studies, typical-sighted readers read the same small text up to ~26% slower in dark mode than in light mode for sustained reading. "Up to" is the ceiling of the measured effect, not a guarantee — it's strongest for long passages of small text, which is why it matters for code and docs specifically.

Why developers actually prefer dark mode (the under-cited reason)

It is tempting to read the table above and conclude "light mode is better, developers are wrong." That misreads it. Developers don't prefer dark mode because it's more legible — it isn't. They prefer it because their working context is the one context where dark mode genuinely wins. Two well-supported 2023–2026 mechanisms explain it, and neither is "reduces eye strain" (the folk claim that the fatigue studies actually fail to confirm):

  1. Luminance matching — glare in a dim room. Visual comfort is governed by the luminance ratio between the screen and its surround. Developers work long hours in dim/low-light rooms. A bright light-mode screen in a dim room is a glare source: the iris has to manage a huge luminance range, and every glance from screen → room → screen forces the pupil to constrict then dilate, a constant pupil-fluctuation workload. Dark mode lowers the screen's output to match the dim surround, removing the glare and the fluctuation. The ergonomic rule is "screen luminance should match ambient" — light-mode-in-a-dark-room is the discomfort; dark-mode-in-a-dark-room is the match (Biology Insights 2025; mechanism aggregated in Superhuman 2026).

  2. Lower perceived mental workload over prolonged sessions. This is the finding most missing from popular writeups: a 2025 eye-tracking study found that dark mode is perceived as significantly less mentally demanding than light mode across task complexities — lower subjective workload — even though pupil dilation (objective load) was higher (ETRA 2025). Meanwhile objective visual fatigue shows no significant difference between modes (MDPI 2025). So the preference optimizes how taxing an 8-hour day in a dim room feels, not reading speed — and that perception is real and measured.

  3. Long days, late hours — and duration is a multiplier. Engineers routinely work 10–14 hour days, much of it after dark and outside 9-to-5. This changes the calculus twice over. First, exposure time compounds the felt cost: a per-task legibility edge that helps a five-minute proofread (positive polarity) is trivial next to hours of screen-vs-dim-room glare mismatch accumulating by hour twelve. The longer the session, the more the dominant variable becomes per-hour comfort, not per-task reading speed — and the dim-room luminance-match argument (point 1) becomes the common case, not an edge case. Polarity research confirms the moderation: no significant polarity advantage in daytime, but light mode degrades at night (While & Sarvghad 2024). Second, a long day spills into circadian-sensitive hours: a bright pre-bed screen is the worst time for high light output — pre-sleep screen exposure is associated with a 33% higher prevalence of poor sleep (JAMA Network Open, n=122,124, via Superhuman 2026), and the American Academy of Ophthalmology notes dark mode emits less light than light mode. A white IDE at hour twelve (1 a.m.) is both more taxing and more melatonin-disruptive than a dark one.

This resolves the apparent paradox. Light mode wins objective legibility in bright/balanced light and short reading tasks (the Piepenbrock paradigm). Dark mode wins subjective comfort and perceived workload in the dim, prolonged conditions developers actually work in. They measure different things; both are true. The developer preference is rational for the context, not a myth — which is exactly why the rule is "default by surface type and respect the user," not "pick a winner."

The honest caveat (cite it too): dark mode's comfort comes with a sharpness cost — the dilated pupil admits more light but increases optical aberrations, and "exacerbates the halation effect, making bright text appear fuzzy or blurred," especially with astigmatism (Biology Insights 2025). That is the direct argument for the tone discipline below: off-white-not-white and near-black-not-black exist to claw back the sharpness the dilated pupil gives up.

How SageOx ships it (the rules)

  1. Both modes, always; respect prefers-color-scheme; never force. Offer light / dark / system. A third of people want each of dark / light / contextual, and astigmatism or photosensitivity makes one mode materially harder for a real minority — choice is the accessibility posture.
  2. Default by surface type (not a global "dark is cooler" reflex):
Surface Default Why
Reading-heavy — docs, transcripts, distillations, long-form, email Light / respect-OS Read in short bursts, often in daylight; positive polarity reads faster, especially small text — and the reader isn't living in the surface for eight hours
Dense tool / dashboard — app shell, cast control, code, metadata panels, live-meeting Dark-first (respect-OS) This is the surface a developer inhabits for hours, frequently late at night in a dim room — the exact condition where dark lowers felt cost (luminance match, lower perceived workload, less melatonin disruption). Optimize it for the prolonged after-hours session, not the one-off read
  1. Each mode independently clears WCAG AA 4.5:1 for normal text — never assume light-mode contrast carries to dark.

This applies to every SageOx surface, not just web — mobile (sageox-app, honor OS Appearance), the ox CLI (respect the terminal background; can't persist a theme), the Speaker / Scribe / OxDot devices (ambient-aware, night-dimming output — the strongest luminance-match case), and the future sageox-desktop. The principle is constant; the application differs per surface (see DDR-008 → "Applies to every SageOx surface").

What developers actually want in a dark theme (tone recipes)

These are the choices that separate a comfortable dark theme from a merely cool one. SageOx already encodes all of them.

Lever Do Don't Why
Base surface Near-black (SageOx green-black Crater crater-800 #111411 over ambient crater-900 #0b0d0b; genre ref Material #121212) Pure black #000000 Pure black can't show elevation, smears on OLED, maximizes halation
Body text Off-white dust-100 #f4f2ef Pure white #ffffff White-on-black is 21:1 — past comfortable, triggers astigmatic halation
Elevation Step to a lighter surface (crater-900 → 800 → 700) A heavier shadow A shadow on near-black is invisible; lightness is depth in dark mode
Accents / syntax Desaturated, lighter stops (sage-400, signal -400s); keep surface chroma low Saturated neon on dark High-chroma colors optically vibrate on dark and miss 4.5:1 at body size
Hue A subtle brand tint is fine (SageOx green-black, OKLCH hue 145, chroma ≤ 0.015) A saturated surface Hue is a free brand axis above the legibility floor; saturation is not

The green-black dark theme (what ships)

The green-black rebrand retired the old cool-neutral near-black and split its dual-use ramp into purpose-built families: Crater for dark surfaces, Dust for text on dark, Silt for borders. The change moved the theme's identity only on the axis research says is free (hue) — every load-bearing axis (luminance ladder, off-white text, low chroma) is held:

Axis Green-black (shipping)
Surface base crater-800 #111411 over ambient crater-900 #0b0d0b (warm green-black — the green cast is the brand)
Surface tokens Dedicated --ox-crater-* ramp (900 base → 700 cards), decoupled from text/border families
Chroma Explicit cap ≤ 0.015, fixed OKLCH hue 145
Body text dust-100 #f4f2ef off-white
Muted text sage-400 #9dc498 (sage tint)
Off-white body / near-black floor / lighten-to-elevate ✓ (held)

The green cast is a luminance-free brand tint laid over an unchanged legibility contract — the reading advantage is a luminance effect, not a hue one.

Accessibility callout

  • Never force a mode. ~47–50% of adults have astigmatism; for many, high-contrast text on dark bleeds. Photosensitive and low-vision users split the other way. Offer the choice (WebAIM, Apr 2025).
  • Soften both ends in dark. Off-white text on near-black, not white-on-black — the contrast ceiling is as real as the floor.
  • Color is never the only signal (DDR-006, §11 Rule 3) — pairs with icon/label in both modes.

Testing checklist

  • Component renders in light, dark, and calm (catalog story covers all three — §11 Rule 7).
  • Each mode independently clears 4.5:1 for normal text (run contrast-check.html per mode).
  • No pure black surface; no pure white body text.
  • Elevation reads in dark mode (lighter surface, not just a shadow).
  • Accents desaturated enough to clear AA at body size and not vibrate.

References