I was squinting at Solarized Light again, wondering why the most popular colour theme felt like looking at the world through dirty glasses. After years of bouncing between dark and light themes, due to the blurry vision and involuntary gazing the dark themes were causing, and apparent lack of contrast of the popular light themes, I’d decided to finally embrace the light—except make it better. That afternoon, frustrated and slightly caffeine-buzzed, I made a decision; I will finally do it. What started as a weekend project turned into a months-long journey through colour perception research, monitor specifications, and the surprising realisation that almost everything we believe about light and colour is wrong.
To actually fix something, I must first understand exactly what’s wrong, so I began to document why those light themes felt amiss.
Solarized Light is a colour theme based on eight accent tones with near-identical lightness, and it’s so famous and “well-received” that almost every code editor bundles one, which naturally was my first light theme choice—it was not “well-received” by my eyes. The issue was apparent: some accent tones looked way too similar, the contrast against yellow paper is inadequate, and the specific yellow and green accent tone chosen by the colour theme was basically unusable: way too similar, way too low contrast, both ranking 2.97:1 exactly by WCAG contrast metrics.
Monokai (Classic) and Monokai Pro are also one of the most famous colour theme, bundled in many code editors. Monokai Pro Dark is actually quite well-made dark theme, and their light version uses different accent tones than its dark counterpart, clearly understanding the difference between light and dark. Nevertheless, the light theme felt inadequate against my office-grade (and the professional-grade one I acquired later) monitors; only one accent colour, purple, achieved 5.29:1 contrast ratio, and the remaining five never surpassed even the 4:1, failing WCAG AA requirements. The worst part was the yellow strings: a barely visible 3.18:1 that made finding typos feel like an eye exam—a highly underwhelming result for the updated, “Pro” version.
And here lies the fundamental question on the light themes: “Why do all light themes with good contrast look like they were designed for a dental office?” These light themes, while readable, willingly sacrifice the colourfulness of the text, turning every accent tone into a different tint of black. The unspoken rule seemed to be: “Dark themes get to be sexy cyberpunk interfaces, but light themes must dress like they are going to a job interview at a bank in the 1980s; or write their résumé in watercolour—gorgeous artistry that no recruiter can actually read.”
Conclusion: we need a light theme that’s functional as well as aesthetic.
I thought I knew what I was looking for: a theme with good contrast ratios and colours that didn’t look like hospital scrubs. Should be simple enough, right? Just pick some nice, saturated colours that pass WCAG AAA requirements, and call it a day.
Then I discovered why everyone before me had failed.
It started innocently enough—I was testing yet another shade of blue, trying to understand why it looked perfect in my colour picker but terrible in my editor. That led me to a Wikipedia article about colour perception. Which led to a research paper. Which led to another paper. Which led to me, at 2 AM, reading about colour appearance models and realising everything I thought I knew about “good contrast” was incomplete at best.
The rabbit hole had opened, and I was already falling.
My first discovery was that lightness (what computers measure) and brightness (what we perceive) are completely different beasts. A hot pink might measure the same lightness as a grey, but our brains scream that the pink is brighter. This phenomenon was another beast named Helmholtz–Kohlrausch Effect in play, and the effect directly alters the brightness of the perceived colour. This gap—between what contrast ratios measure and what we actually see—was the key everyone had been missing.
This meant I could use more saturated colours than traditional themes dared to try. While they stayed safe with muted tones, I could push saturation higher and let the H–K effect do the heavy lifting for perceived contrast.
But then I hit a wall. Even with perfectly chosen colours, text felt… thin. Wispy. Like it was floating above the screen rather than sitting on it.
After diving through vision research papers, I found the culprit: black text on white backgrounds suffers from what researchers call “irradiation”—the white background literally eats into the dark letters, making them appear thinner than they are. It’s why books have used off-white paper for centuries, and why e-readers never display pure white.
The research was unanimous: white-on-black text appears bolder and more substantial, while black-on-white needs compensation. This explained why so many light themes felt anaemic—they were fighting a battle against physics and losing.
Armed with this knowledge, I started experimenting with backgrounds. Pure white (#FFFFFF) was clearly too harsh, but how far could I push it? That’s when I discovered something the colour theory books don’t tell you: monitors lie.
Here’s what I found: consumer monitors have a dramatic brightness cliff between #FFFFFF and #FEFEFE. That single bit difference—imperceptible in theory—triggers a significant brightness reduction on actual displays. The jump from #FEFEFE to #FDFDFD? Barely noticeable. But #FFFFFF is special, pushed to maximum backlight intensity.
It’s like monitor manufacturers conspired to make pure white as bright as possible, creating a secret brightness level that only #FFFFFF can access. By choosing #FDFDFD, I wasn’t just reducing brightness by 1%—I was opting out of the “stare into the sun” mode entirely while keeping the “premium paper” look.
These three discoveries changed everything:
Suddenly, the failures of existing themes made sense. They were either unaware of these effects or too conservative to exploit them. But I had no reputation to protect, no committee to please—just my own eyes demanding better.
Time to put theory into practice.
With three revelations in hand, I opened my colour picker with the confidence of someone who’d just read the manual to a game everyone else was playing blind.
I was wrong. Theory and practice, it turns out, are different beasts entirely.
My first attempt was embarrassing. I cranked up the saturation on every colour, trusting the Helmholtz–Kohlrausch effect to save me. The result looked like a unicorn had thrown up on my screen. Too much of a good thing, apparently.
That’s when I discovered MacAdam Limits—essentially a map showing the maximum possible saturation for each hue, and this map revealed something crucial: not all colours are created equal. Yellow tops out early, becoming impossible to saturate without losing contrast. But teal, blue, purple, and red? These colours had room to breathe, space to push into territories that yellow could never reach.
It was like discovering that my dungeon had secret passages, but only in certain directions. The cyan-blue-purple-red spectrum became my new playground. These weren’t arbitrary choices—they were the colours physics allowed me to make bold.
The effect was even more pronounced on different displays. On my ancient HP ProBook, the colours finally popped instead of mudding together. On my MacBook’s P3 display, they sang. Same theme, different performances, all good—exactly what I’d hoped for.
In my first iterations, the strings were green. Of course they were—every theme I’d ever used had green strings. It was comfortable, familiar, like a worn pair of coding socks.
But after adjusting other colours, green became the weak link. It sat there, polite and inadequate, with the contrast of wet cardboard. The MacAdam Limits confirmed what my eyes knew: green just couldn’t compete in the saturation game.
Of the remaining hues, red immediately caught my eye. But red strings? That felt like heresy. Red meant errors, warnings, danger—not innocent text content.
I tried it anyway.
The strings didn’t just stand out—they demanded attention. Every unclosed quote, every string typo became instantly visible. What I’d stumbled onto by accident, research later confirmed: red enhances detail-oriented cognitive processing. My “heretical” choice was actually helping my brain spot mistakes.
So I refined it, testing shade after shade until I found the sweet spot: #BF0303. Bold enough to command attention, refined enough not to scream “EMERGENCY!” at every string declaration.
Here’s where I broke another unwritten rule: syntax themes should use colour, period. Bold is for keywords in documentation, not code. Italics are for comments in books, not IDEs.
But I had a limited palette and big ambitions. If I couldn’t add more colours (physics said no), I could add more dimensions. Bold keywords didn’t just solve the irradiation problem—they created visual hierarchy. Important control structures literally carried more weight.
Italics for certain constructs added rhythm. Underlines for mutable variables made them unmistakable. The code began to dance on the screen, each font style adding meaning that colour alone couldn’t convey.
The unexpected benefit? This approach would help colourblind developers too. By varying typography alongside colour, I’d accidentally created multiple ways to distinguish syntax elements. A colourblind developer wouldn’t need to rely solely on distinguishing red from green—they’d have bold keywords, italic constants, and underlined mutable variables as additional cues. It wasn’t planned, but constraints have a way of forcing better solutions.
Each decision built on the last. Bold keywords enabled ocean-depth blue. Red strings freed green from its misery. Typography added the dynamics that a limited palette couldn’t provide.
Syntello wasn’t just a collection of colours anymore—it was a system, each part reinforcing the others. The theme that started as “let me fix these broken light themes” had become something else entirely: proof that light themes could be both beautiful and functional.
But would anyone else see it that way?
Six months after that caffeine-fueled afternoon, I’m still using Syntello daily. My eyes no longer squint. The involuntary gazing is gone. The code is crisp, clear, and—dare I say it—beautiful.
But here’s what I didn’t expect: the comments from other developers. “I thought I hated light themes,” they’d say. “Turns out I just hated bad ones.” Or my favourite: “I can finally code past 3 PM without feeling like my retinas are filing a complaint.”
Let’s be honest: if you're happy with your dark theme, Syntello probably isn’t for you—and that’s fine. The cyberpunk aesthetic is alluring, and if your eyes don’t protest, why change?
But if you’re like I was—caught between dark themes that cause focus issues and light themes that look like medical software—then maybe it’s worth trying something different. Your visual system might surprise you.
Building Syntello revealed something beyond colour codes and contrast ratios: most of our “preferences” in development environments are just accumulated habits. We use dark themes because everyone uses dark themes. We accept muddy light themes because we assume that’s the price of readability.
Sometimes the best solutions come from questioning these assumptions. From diving into research papers at 2 AM. From discovering that monitor manufacturers have been gaslighting us with #FFFFFF. From realising that red strings aren’t heretical—they’re helpful.
Syntello is open source and available for JetBrains IDEs (IntelliJ IDEA, WebStorm, PyCharm, Android Studio, etc.), Kate, Sublime Text, and Visual Studio Code. Try it for a week. Your pupils will constrict, your irradiation problems will vanish, and the Helmholtz–Kohlrausch effect will make those colours sing.
Will you love it immediately? Probably not. Light themes require adjustment, like walking outside after a movie. But give your visual system time to adapt. You might discover, as I did, that you don’t hate light themes.
You just hate bad ones.