The Dark Side of Mint Green
I followed a swatch (green, not white) through Gmail's dark mode and tested four color-mapping methods to see what sticks
A friend sent me an email that spun me down the most wondrous rabbit hole, early on a Wednesday morning. I was very interested in the content, of course, but what caught my attention was how the text, in dark mode in the Gmail app on my iPhone, was the most peculiar shade of muted mint green.
How, though was the text that color? It was immediately obvious that the case was interesting, bridging insomnia with my swatch-collector nature. I needed to know more.
I wondered if it was even possible to use that specific shade of green (#BDDAA4 / rgb(189, 218, 164)) to compose an email in Gmail:
- On iOS, Google does not include the option to select the text color – or it's very well hidden.
- You can't choose that exact color in a browser, either. Gmail's support for dark mode is still clunky: even when using a dark theme, it only partly applies, and the Compose window stays light. You can force dark in Chrome (chrome://flags/#enable-force-dark), but the results are still rough. Hardly anybody could use that for work, especially for a symmetry-loving person like the email's sender.
- Perhaps the mint green was picked in Gmail while in light mode, even though the type would be barely visible on a white background. Yet the swatches available in the Gmail app do not include #BDDAA4. Google offers similar greens, but not the same. The lightest shade in the palette is #D9EAD3 / rgb(217, 234, 211), and the step after that is #B6D7A8 / rgb(182, 215, 168): very, very close, but not identical.
- It is technically possible to hack formatting in an outgoing email by tweaking the HTML in Chrome's inspector, but it's niche and brittle and again seems like a long-shot possibility.
- Gmail on Android comes with a color picker for text, but that too does not include #BDDAA4 (which also covers the possibility that I simply didn’t look hard enough for the formatting options on iOS)
- Because the headers are Gmail-specific (
Message-IDends in@mail.gmail.comand I could seeX-Gm-Message-State, X-Gm-Features, andX-Google-DKIM-Signature/X-Google-Smtp-Source) and there's noUser-Agent/X-Mailerfrom Outlook or Apple Mail, this was sent via Gmail's web interface, not a third-party client. I googled all that.
"It has been argued by me, the defense, that two sets of guys met up at the Sac-O-Suds, at the same time, driving identical metallic mint-green 1964 Buick Skylark convertibles… Now, can you tell us if the defense's case holds water?"
"No, the defense is wrong."
I checked how the text looks in a desktop browser in light mode: still green, but a deep, dark shade, #274E13 / rgb(39, 78, 19). This time it was one from Google's palette, the darkest green (between teal and mustard).
Then I checked computed CSS in the Gmail app on iOS with Chrome's flag force-enabled. As expected, even though I was seeing the muted mint green on a dark gray background, the inspector listed the color as #274E13 (the dark one). So, as I suspected, the muted mint was a product of algorithmic color remapping.
I still had to figure out how and why the color shifts from #274E13 to #BDDAA4. While I was at it, I was curious how the rest of the dark colors in Google's palette would map in dark mode, so I sent the following email to myself.
And this is what I was seeing in dark mode.
After doing some digging, I learned that there are only a handful of ways developers usually handle the intricacies of dark and light modes. In Google's case there's no public spec for the exact remapping so we are free to guess and play.
Method 1: Simple RGB Invert
How it works. Like a photo negative: flip each channel (R, G, B) to 255 - x.
Result. For #274E13, you get a pale lavender, nowhere near mint.
Method 2: HSL "Flip Lightness"
How it works. Convert to HSL, mirror the L (lightness), keep H (hue), modestly temper S (saturation).
Result. Closer. You get a pale green in the right family, often too bright or candy-colored.
Method 3: Lab/OKLCH "Perceptual Flip"
How it works. Use a perceptual model; flip L* (lightness) and reduce chroma to avoid neon blow-outs.
Result. A natural-looking muted mint, visually convincing, but not contrast-aware.
Method 4: Contrast-Targeted Remap
How it works: This method prioritizes readability. It automatically adjusts the color's brightness until it achieves a specific contrast ratio against a dark background. While it adjusts the brightness, it tries to preserve the original color and soften its saturation.
Result. Practical and consistent. This lands #274E13 in the #B6C9A9–#BDDAA4 band: readable, minty, not harsh.
Final verdict
🥇 Contrast-targeted remap (Method 4) wins. It's the only one that reliably pushes #274E13 up to a readable, muted green in dark mode (landing in the #B6C9A9–#BDDAA4 band) because it optimizes for contrast while roughly preserving hue and softening saturation.
🥈 Runner-up: Lab/OKLCH flip (Method 3) plus a small chroma cut and a slight lightness lift can also hit #BDDAA4, but it isn't contrast-aware, so the result varies with background.
🥉 HSL flip (Method 2) is close but often too bright;
RGB invert (Method 1) lands in the wrong hue entirely.
Key takeaway
Method 4 is best for text (readability first), and Method 3 for swatches/UI accents where we get a satisfying mint but with no need to brighten it to accommodate text.
Turns out joining the dark side is much, much easier than the other way around. If we try to use the same algorithms to go from light text colors on a dark background to dark, saturated colors on a white background, well, we don't get much – especially from Method 4, which shoots the brightness up and produces barely visible swatches.
The problem is that the light swatches start with low chroma and often warm hues, so the darkening step (vs. white) must add saturation and subtly steer the hue to avoid brown or steel drift. That breaks the symmetry that made HSL flip, Lab flip with chroma damping, and contrast-targeted remap (which raised L* on dark backgrounds) work so well in the original block.
We tried chroma-gain ramps for Method 3; a WCAG-driven downward remap for Method 4 plus hue steering and a gamut-aware saturation push; and even RGB invert (Method 1) as a baseline. But they still match Gmail's deep tones far less consistently than the dark cases. More often than not, we end up with a muddy brown.
One assumption is that, in applying some variation of Method 4, Google may hard-code its eight colors so it doesn't need chroma or saturation in the initial light swatch. The system knows it's operating in the house of reds or the house of purples. In other words, a palette-aware post-step likely snaps the result to the nearest hue “rail” after it hits WCAG contrast, keeping a red recognizably red even when the math would drift toward brown. Methods 2 and 3 don't get close even with cheat mode on. It may not be a coincidence that the palette is relatively contained and that choosing just any color we want isn't encouraged.
And of course, all of this could be purely my imagination (isn't that the stuff rabbit holes are made of?).