Solarized, Monokai, and Dracula: The Design History Hiding in Your Code Editor

Open ten different code editors and something strange happens. Every single one colors comments gray. Every one gives strings their own consistent shade. Every one makes keywords bold or saturated while variables stay quiet. No governing body wrote this rulebook. No committee voted on it. And yet a Python file in VS Code, a Rust file in JetBrains, and a shell script in Vim all follow roughly the same visual logic, even though their creators built these tools decades apart and never coordinated on color.

That consistency looks like a coincidence. It isn't. It's the result of a handful of programmers who treated syntax highlighting as a real design problem, made specific, documented decisions about hue and contrast, and then had their choices copied by almost everyone who came after them. Their work is worth understanding, because most developers spend more hours looking at these colors than at any palette a professional designer ever ships.

A pedagogy tool wearing a programmer's disguise

Syntax highlighting didn't start as decoration. It started as a teaching aid.

The earliest known syntax-aware editor was Emily, built in 1969 by Wilfred Hansen at Stanford's Augmentation Research Center. Emily used structural cues to stop programmers from typing code that didn't parse, an early attempt to make the editor understand language, not just text. The first color-based system followed over a decade later: Anita H. Klock and Jan B. Chodak filed a patent in 1982 for a syntax highlighting method that shipped in 1983 inside the Intellivision's Entertainment Computer System, a keyboard peripheral meant to teach BASIC to home users on a game console. The goal wasn't visual polish. It was helping beginners tell a command from a variable.

Color syntax highlighting on a real screen, with live parsing, arrived in 1985 with LEXX, an editor Mike Cowlishaw built at IBM for the Oxford English Dictionary's computerization project. The same year, MacPascal 1.0 shipped on the Macintosh and used bold text for keywords, since its monochrome display couldn't do color at all. Semantic highlighting, which colors a specific variable differently everywhere it's used rather than just tagging its type, didn't show up until KDevelop introduced it in 2009. Visual Studio and Xcode picked up the idea after 2014.

None of this reads like an aesthetic movement. It reads like a series of engineers solving the same narrow problem: how do you make a wall of identical-looking text tell you, at a glance, what kind of thing you're looking at. The aesthetics came later, once that functional groundwork already existed.

The six things every theme agrees to highlight

Part of why every modern editor looks structurally similar traces back to one convention: the TextMate scope naming system, documented in the mid-2000s and still used by Sublime Text, VS Code, and most other editors today. A scope is a dot-separated label, from general to specific, like keyword.control.php. Themes don't target languages directly. They target scopes, which is why the same theme file can color Python, Rust, and PHP consistently without knowing anything about any of them.

The standard categories are narrower than you'd guess. There's keyword for control words and operators, entity for the name of a function, class, or module where it's defined, constant for fixed values like numbers and hex codes, storage for type annotations such as var, let, or int, string for text literals, and comment for, well, comments. Six or seven roles cover almost everything a programming language needs to distinguish. That's a small, disciplined palette by design, not an accident of laziness. A theme that assigns a distinct hue to every possible token type stops being readable. It starts looking like a rainbow spreadsheet.

Six months with a color science textbook

Ethan Schoonover built the most academically rigorous of the popular themes. In 2010, frustrated that his editor's schemes were either blinding white-on-black or low contrast in ways that made some colors disappear entirely, he spent six months researching color perception before writing a single hex value. He published the result, Solarized, on GitHub in April 2011.

Schoonover's core insight borrowed from print, not screens. Reading a book in direct sun tires your eyes fast, but reading the same book in the shade of a tree, where the paper still contrasts clearly with the ink, doesn't. Most editor themes at the time were the equivalent of reading in direct sun: black text on pure white, or white text on pure black, both near the maximum contrast a monitor can produce. Solarized deliberately pulled that contrast down while keeping the hues themselves clearly separated on the color wheel, so code stayed legible without the glare.

To make that work, Schoonover built the palette in the CIELAB color space rather than picking RGB values by eye, so the lightness relationships between colors would stay perceptually consistent rather than just numerically consistent. He also accounted for the Helmholtz-Kohlrausch effect, the well-documented phenomenon where a saturated color looks brighter than a desaturated one of the same measured luminance, which is why a badly designed theme can have two colors that are "equally light" on paper but wildly mismatched on screen. The final palette has sixteen colors, eight muted base tones for backgrounds and text, and eight accent colors for syntax, with the light and dark variants built to mirror each other's contrast rather than being two unrelated color sets.

A stolen laptop and a color that outgrew its creator

Not every popular theme came from a research process. Some came from taste, repeated until it stuck.

Wimer Hazenberg built Monokai in 2006 for TextMate on macOS, unhappy with the oversaturated defaults available at the time. He picked a dark background, a pink for keywords, and a vanilla yellow for strings, a palette built on instinct and a photography background rather than a spreadsheet of measurements. It worked well enough that when Sublime Text launched and needed a default theme, Monokai got the job, which is how a scheme two people mostly know from one designer's TextMate blog became one of the most-installed color schemes in software.

Dracula has an even less deliberate origin story. Zeno Rocha's laptop was stolen in Madrid in 2013, and reconfiguring every tool from scratch left him annoyed at how inconsistent his various apps looked next to each other. He built one theme and ported it everywhere: terminal, editor, browser, anywhere he could inject a stylesheet. The first public version shipped for Zsh on October 27, 2013. Dracula's palette centers on a dark slate background (#282a36) and off-white foreground (#f8f8f2), with cyan (#8be9fd), green (#50fa7b), pink (#ff79c6), purple (#bd93f9), and red (#ff5555) doing the syntax work. By Rocha's own count, Dracula now supports over 218 applications, and according to a comparison he posted using data from a GitHub star-tracking tool, it passed Solarized to become the most-starred theme repository on the platform.

Two very different processes, six months of CIELAB math versus a theme built to survive a stolen laptop, and both ended up as defaults that millions of programmers now stare at without a second thought.

The colorblind blind spot in highlighted code

Almost none of this history considered color vision deficiency, and that gap shows. The American Optometric Association puts the numbers at about 8% of white men and roughly 0.5% of women, since the condition is carried on the X chromosome and mostly shows up in men. For a theme that leans on red for errors and green for strings or success states, that's not a rounding error. It's a meaningful share of every engineering team unable to reliably tell two token types apart at a glance.

The fix already exists outside the programming world. Paul Tol, an astrophysicist at the Netherlands Institute for Space Research, publishes a set of qualitative color schemes built specifically to stay distinguishable under the most common forms of color blindness. His "bright" palette uses blue (#4477AA), red (#EE6677), green (#228833), yellow (#CCBB44), cyan (#66CCEE), purple (#AA3377), and grey (#BBBBBB), chosen so that no two colors collapse into each other under deuteranopia or protanopia simulation. A handful of accessible syntax themes, including colorblind-specific variants of the Pygments styles used in many documentation tools, already build on schemes like this. Most mainstream editor themes still don't.

Dark mode doesn't earn its reputation

Programmer culture treats a dark theme as an article of faith: it's easier on the eyes, it's what serious developers use, end of discussion. The actual research complicates that.

A study by Piepenbrock and colleagues, published in the journal Human Factors in 2013, tested visual acuity and proofreading performance in both younger adults (18 to 33) and older adults (60 to 85) with normal vision. Light mode won across every measured dimension for both age groups, and the advantage grew as text got smaller. Yet across this body of research, self-reported eye strain, headaches, and muscle fatigue showed no significant difference between the two modes. That undercuts the assumption that dark backgrounds are objectively gentler on the eyes.

Context still matters. A 2017 MIT AgeLab study by Dobres and colleagues, looking at quick glances at small screens like phones and smartwatches, found no meaningful difference between light and dark text during the day, but light mode, dark text on a light background, held a real advantage for reading at night, especially with small fonts. And a separate study by Aleman and colleagues in 2018 linked light mode reading with thinning of the choroid membrane, raising a long-term question about myopia risk that outweighs any short-term performance edge. None of this settles the debate cleanly. It does mean the "dark mode is healthier" claim is doing more cultural work than scientific work.

Building your own theme, one decision at a time

You don't need Schoonover's six months to design a syntax theme that holds up. You need a short, ordered set of decisions.

Start with contrast, not color. WCAG 2.1 sets a 4.5:1 contrast ratio for normal text at Level AA, and 3:1 for large text. That standard exists for body copy, but code benefits from the same discipline, especially for anything a developer reads for hours at a stretch. Pick your background and default text color first, check the ratio, and only then start assigning hues to token types.

Next, assign hue by role, not habit. Limit yourself to the categories that earn a distinct color: keywords, strings, comments, functions or entity names, and constants. Five or six roles is plenty. Adding a seventh or eighth color for a token type nobody scans for just adds noise.

Reserve your most alarming color, usually a saturated red, for something that means "pay attention," like an actual error or a deprecated call. If red is also your string color, you've spent your one attention-grabbing hue on something the reader sees constantly and needs to ignore.

Check the result under a color blindness simulator before you ship it. Chrome DevTools, Figma, and several free browser extensions can simulate deuteranopia and protanopia directly. If two of your token colors collapse into the same simulated shade, swap one for something further apart on the wheel, the way Paul Tol's schemes already do.

Finally, if you're building both a light and a dark variant, don't treat them as two unrelated projects. Solarized's trick, matching the perceptual lightness relationships between the two rather than just picking colors that individually look nice, is the reason its light and dark versions feel like siblings instead of strangers.

Here's a starting point built on those rules, using colorblind-safe hues in place of the red-green defaults most themes reach for first:

A dark theme keeps the background low in brightness while giving each token role a hue far enough from its neighbors to survive a color vision test:

A light theme flips the relationship, using darker, more saturated versions of the same hues against a near-white background so the contrast ratio holds without the colors turning muddy:

Neither palette is trying to look unusual. That's the point. A good syntax theme disappears into the background of reading code, which is what Hansen, Klock, Chodak, Cowlishaw, Schoonover, Hazenberg, and Rocha were all building toward, whether they knew it or not.