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 collects every text/background color pair in your email and runs each pair through measured models of real clients. On the Content tab it reads the live design itself; on the preview tabs it walks the rendered email. It gives you three things:

• 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). Scans run automatically: when the panel opens, as you edit, and after a save.
• An in-place preview. On a preview tab, pick a client and the panel recolors the preview to show how that client would render your email in dark mode.
• An auto-fixer. On the Content tab, Nitro can rewrite the risky colors for you, preview the result on the canvas, and stage it for Blueshift’s Save. See Auto-fix below.

Under the hood, the transform is a hue-preserving lightness remap in CIELAB color space, not an RGB inversion. 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:

Reading the findings

Findings are ranked by what is actually actionable, most severe first:

Using it

• Enable Dark Mode in the Nitro popup.
• Open a template in Email Template Studio. The Dark Mode launcher pill shows a live risk count, and turns red when there is something to look at.
• Click the pill; a floating, draggable panel opens and scans immediately. There is no scan button to press: the findings refresh as you edit and after every save.
• A banner reports whether the email declares color-scheme, and expands to explain which clients honor it.
• On a preview tab (Data or Test), pick a client model to recolor the preview in place. Switch models to compare; switch back to restore. Findings are always checked across all clients; the selector only changes the preview.
• Review the findings list and fix the root causes by hand, or use Auto-fix on the Content tab.
• When a scan comes back clean, the panel says so and gets out of your way.

Auto-fix

On the Content tab, the panel’s Auto-fix contrast section can rewrite risky colors for you. It solves each flagged pair in CIELAB space, keeping hue and character while moving lightness just far enough that the pair passes in every measured client. A fix only counts as a fix when the scanner itself finds nothing left to flag.

• The balance slider decides which side of each pair may move, in five stops from “Only change text colors” to “Only change background colors.” The default splits changes evenly.
• Two opt-ins stay off until you say so. Backgrounds shared by multiple elements (a row’s fill, the page background) are only changed if you allow it, and are then solved once for every text sitting on them, so fixing one block can’t break a sibling. Color variables in configurable shared assets can also be rewritten; only the values assigned in your template’s blocks are touched, never the shared asset itself.
• Preview fixes applies the result to the canvas so you can see it. Keep stages it for Blueshift’s Save; Revert restores the original. Nothing persists until you click Blueshift’s own Save button.
• Anything that can’t be fixed under the current settings is called out with the reason and the lever to pull: allow a shared change, try a different slider balance, or rework the pair by hand.
• When everything is fixed, the panel collapses to a clean bill of health and reminds you to save.

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 color property 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-scheme declaration, so every client applies its automatic transform to be measured.
• 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.