Dark Mode Preview
Experimental · Feedback wanted
The problem
Email clients don’t just display your email in dark mode; many of them rewrite your colors. Each one rewrites them differently, none of them document how, and some of them will destroy a color combination that looked perfect in the editor.
Until now the only reliable way to know was to mail yourself a test and check it in every client, in dark mode, one by one. Most teams don’t, most of the time, and the result is invisible text and vanished buttons for the 30–40% of readers who use dark mode.
Worse, the intuitive mental model (“dark mode inverts colors, like a photo negative”) is wrong. Real clients preserve hue, largely spare saturated brand colors, and treat text and backgrounds differently. Tools that simulate dark mode with naive RGB inversion give you wrong answers with confidence.
How it works
Dark Mode Preview reads the rendered email in the preview pane, walks the document collecting every text/background color pair, and runs each pair through measured models of real clients. It gives you two things:
- An in-place preview. Pick a client and the panel recolors the preview to show how that client would render your email in dark mode. The change is applied only to the preview pane and is fully reversible.
- A findings list. Every color pair whose contrast breaks under some client’s transform, ranked by severity, with the reason and the before/after contrast ratios (checked against WCAG AA: 4.5:1 for body text, 3:1 for large text).
Under the hood, the transform is a hue-preserving lightness remap in CIELAB color space, not an RGB negation. That matches how clients actually behave: hue survives, saturated mid-lightness colors barely move, and the interesting action is all in how each client re-maps lightness.
The three client families
Measured behavior sorts email clients into three families:
| Family | Behavior | Clients |
|---|---|---|
| None | Leaves your colors alone, when the email declares color-scheme and the client respects it. |
Apple Mail (dark-aware emails), most webmail |
| Partial | Only light backgrounds are darkened; dark backgrounds are left alone; dark text is lightened. Each client has its own cutoffs; Gmail on Android is conservative (roughly, backgrounds up to #cccccc survive), Outlook starts remapping much earlier. | Gmail app (Android), Outlook.com, Outlook app |
| Full invert | Every color’s lightness flips in a compressed photo-negative (measured: black lands near white, white lands near very dark gray). Dark-designed emails get wrecked. Highest risk. | Outlook classic (Windows), Gmail app (iOS), Apple Mail when the email declares no color-scheme |
color-scheme: light dark moves Apple Mail from the destructive
“full invert” family into the harmless “none” family.
Gmail and Outlook ignore the declaration, but for Apple readers it is a
one-line fix.
Reading the findings
Findings are ranked by what is actually actionable, most severe first:
| Finding | What it means | The fix |
|---|---|---|
| Translucent break | A semi-transparent color re-composites over the inverted canvas and loses contrast. The most common real-world breakage. | Use a solid color instead of alpha transparency. |
| Contrast collapse | An opaque pair that breaks in (nearly) every inverting client. Rare, because faithful transforms mostly preserve contrast for clean opaque pairs. | Rework the pair; there is no client where it survives. |
| Already below AA | The pair was under the accessibility floor before dark mode ever touched it. | Fix it regardless of dark mode. |
| Client divergence | Readable in some clients, broken in others; usually a color sitting right at one client’s light/dark cutoff. | Nudge the color away from the threshold. |
| Degraded | Still passes everywhere, but the ratio drops sharply and lands near the line. | Worth a look if the text is small or thin. |
Using it
- Enable Dark Mode in the Nitro popup.
- Open a template preview (Data or Test tab) and click the Dark Mode launcher; a floating, draggable panel opens.
- Pick a client model to recolor the preview in place. Switch models to compare; switch back to normal to restore.
- Review the findings list and fix the root causes, starting from the top.
- Nothing is written to Blueshift; the panel only recolors the preview pane, and a preview refresh resets everything.
Methodology: the swatch grid
The client models aren’t guesses or vendor documentation (there is none). They were measured with a purpose-built calibration email: a color-combo matrix designed to reverse-engineer each client’s transform.
-
The grid. Two neutral ramp rows stepping from black to white
(revealing each client’s lightness curve and its light/dark threshold),
nine lightness rows by eight hue columns (measuring chroma handling and hue
preservation), and two text ramps rendered as solid block glyphs, because
clients recolor the
colorproperty under different rules than backgrounds. - Built to be sampled by a machine. Every cell is identical in size, a solid magenta bar above and cyan bar below bracket the grid as fiducials that survive any recoloring, and each cell keeps a clean text-free zone so an automated sampler can read the exact rendered color.
-
Email-safe on purpose. Tables, inline styles, no modern CSS,
and deliberately no
color-schemedeclaration, so every client applies its automatic transform to be measured. A second, dark-aware copy of the grid confirms the “none” path for clients that respect the declaration. - Rendered by real clients. The grid was run through inbox preview renders across Gmail (Android and iOS, which differ), Outlook.com, Outlook classic on Windows, and Apple Mail, in dark mode, then each swatch was pixel-sampled: source color in, rendered color out.
- Fitted in Lab space. The samples showed hue held steady while lightness moved along client-specific curves, so each client’s transform is stored as a small set of measured CIELAB lightness parameters. The models are pure data, so they can be re-calibrated as clients change without touching the simulation logic.
Caveats
- Preview-farm renders are a faithful proxy, but not a physical device in your hand. Treat edge-of-threshold results with judgment.
- The models capture each client’s per-color remap, not Gmail’s contextual decision about whether to invert a given region, which doesn’t reduce to a per-color rule.
- This feature is experimental and improves with real-world reports. If a client renders something differently than Nitro predicted, tell me about it; that is exactly the feedback that tunes the models.