Named colors on the web: CSS color names

Early days: HTML and "web‑safe" colors

In the early web:

• HTML supported a small set of named colors like red, blue, green, aqua, teal.
• Designers often worked with "web‑safe" colors – a subset of RGB values that displayed reasonably well on 256‑color monitors. Named colors were part of that mindset: easy to remember, good enough for simple sites.

X11 and the expansion of names

Later, the web borrowed a larger list of color keywords from the X11 window system. That's where many slightly odd names come from:

• cornsilk, lavenderblush, peachpuff, papayawhip,
• lightseagreen, darkslategray, midnightblue, and many more.

These names were never designed for web UIs specifically; they were general‑purpose color names that happened to be available.

CSS Color specifications

As CSS evolved, the list was standardised:

• CSS Color Level 1 and 2 defined the initial set of keywords.
• CSS Color Level 3 and later refined and clarified them.
• Today, all modern browsers support 147 named colors, plus the special keywords transparent, currentColor, and system‑related values.

This means you can write:

color: tomato;
background: cornsilk;
border-color: darkslategray;

and every modern browser will understand it.

The story of rebeccapurple

One of the most famous names is rebeccapurple.

• It was added to CSS in memory of Rebecca Meyer, daughter of web standards and CSS expert Eric Meyer, who passed away from cancer at the age of six.
• Her favourite color was a specific shade of purple (#663399).
• The CSS community proposed adding rebeccapurple as a named color to honour her, and it was accepted into the spec.

CSS defines a fixed mapping from keywords to sRGB values. For example:

These are case‑insensitive: Tomato, TOMATO, and tomato all mean the same color.

Unlike your own design tokens (e.g. --color-primary), these names:

• are global and have the same meaning on every site
• cannot be redefined
• are purely tied to specific RGB/hex values

1. Prototyping and teaching

For quick experiments, code examples or tutorials, named colors are:

• easy to read (background: lightgray;)
• easy to remember (border: orange;)
• good enough to illustrate a concept without focusing on exact values

They're perfect when clarity of meaning is more important than precise brand color.

2. Very simple UIs and internal tools

If you're building:

• a small internal dashboard
• a demo page
• throwaway prototypes

using standard names like white, black, gray, red, green, blue can be perfectly fine. You avoid over‑engineering and keep CSS readable.

3. Accessible defaults

Some named colors have reasonable contrast when used thoughtfully:

• black / white
• darker neutrals (dimgray, slategray)
• strong accent colors (red, blue, seagreen)

For quick accessible combinations, names can be a fast way to pick something "good enough", especially combined with a contrast checker.

For most production‑quality design systems, relying heavily on named colors has drawbacks.

1. Lack of structure

Named colors:

• don't form ordered scales (no blue-50 → blue-900 pattern)
• don't guarantee even spacing in lightness or saturation
• were not designed for UI surfaces, states, or roles

This makes them hard to use for systematic palettes: you can't easily say "one step lighter than royalblue" using names alone.

2. No connection to design tokens

Modern UIs are built around tokens and roles:

• --color-primary, --color-surface, --color-text-muted
• success, warning, error states
• light/dark themes

Named colors are hard‑coded values with no semantic meaning attached. They don't tell you:

• whether tomato is supposed to be a primary action color or an error color
• how cornsilk fits into your neutral scale
• which named color to use for hover, active or focus states

3. Inconsistent aesthetics

Because the names come from various historical sources (X11, early HTML, later additions), the set as a whole:

• is not tuned for modern UI aesthetics
• contains many colors that clash or feel dated when used together
• doesn't help you design consistent light/dark themes

If you want a polished visual language, you'll almost always get a better result by starting from a purpose‑built palette (Tailwind, Material, Radix, Open Color, etc.) instead of raw CSS names.

Here are some practical rules of thumb:

On Colorr, the CSS Named Colors collection gives you:

• a browsable list of all standard color keywords
• for each color: its keyword, hex, RGB, HSL, OKLCH values, tints and shades, and contrast against common backgrounds

You can use this to:

• learn where named colors sit in color space
• quickly translate a keyword you used in a prototype into a structured palette value
• see whether a named color is a good candidate for a particular UI role, or if you should pick a better‑behaved alternative