What CSS named colors actually are
CSS defines a fixed mapping from 147 color names to sRGB values — from simple (red, blue) to modifier names (lightgray, darkslateblue) to whimsical (papayawhip, rebeccapurple).
color: tomato; /* #ff6347 */ background: cornsilk; /* #fff8dc */ border-color: teal; /* #008080 */
They are case-insensitive global keywords — values are fixed and standardised across browsers, tied to sRGB. They were designed for convenience, not for design systems.
What modern palettes add
Modern systems like Tailwind, Radix, Material and Open Color introduce three big changes:
Structured scales
Numeric steps that reliably go from light to dark: Tailwind blue-50→blue-900, Radix blue1→blue12, Material Blue 50→900. Makes it easy to pick tints/shades for backgrounds, text, borders and states.
Semantics and roles
Tokens like primary, surface, error, warning, info, onPrimary — decoupling what a color means from its raw hex value.
Better colour science and accessibility
Many modern palettes are designed in perceptual spaces (Lab/LCH/OKLCH). Steps are tuned for predictable contrast, light/dark theming, and data density.
Where CSS color names still shine
Prototyping and pedagogy
For examples and learning, background: dodgerblue; is more approachable than background: #1e40af;. Names are easier to remember, easier to talk about in tutorials, and good enough to illustrate layout and interaction concepts without worrying about exact brand values.
Very small / internal tools
If you're building single-purpose internal tools, one-off demos, or small UI elements in docs, using gray, lightgray, red, blue may be perfectly adequate. Over-engineering a full palette isn't always worth it.
Quick tweaks in browser devtools
Typing tomato, khaki or thistle can be faster than editing hex digits when exploring qualitative changes live before translating to system colors.
Where named colors fall short
No scales, no progression
There's no tomato-100, tomato-700, or consistent notion of "one step lighter/darker midtone". To build a button family — background, hover, active, outline — you either manually guess related names (salmon, orangered, firebrick) or fall back to hex/HSL anyway.
Modern palettes give you direct progression: blue-500 → blue-600 → blue-700, tuned to be roughly even.
No semantics or roles
Keywords don't encode meaning. Is tomato your brand color or your error color? As your app grows, "just using red for errors" quickly becomes multiple slightly different red values, inconsistent usage across components, and a nightmare to rebrand.
Token-based systems (--color-error, --color-primary) are more maintainable, easier to theme, and clearer to reason about.
Harder to support dark mode and accessibility
Color keywords don't come in light/dark pairs, don't guarantee any particular contrast, and weren't designed for layered surfaces or elevated UI. Designing a consistent dark theme with accessible text, surface tints, overlays and states is painful starting from keywords alone.
Practical migration pattern
Inventory
List all color keywords in your styles. Map each to its actual hex/sRGB value via ColorR's CSS Named Colors collection.
Group by intent
For each named color, determine its role: primary brand/accent, default text, error/warning/success, or decorative background.
Choose a modern palette per role
e.g. error → Tailwind red-50–red-700, success → emerald-50–emerald-700. Pick steps that match the old visual feel and meet contrast requirements.
Introduce tokens
Create a CSS variable layer (--color-primary, --color-error, --color-bg). Refactor components to use tokens instead of names.
:root {
--color-primary: #2563eb; /* blue-600 */
--color-error: #dc2626; /* red-600 */
--color-bg: #f9fafb; /* gray-50 */
}
.button-primary {
background: var(--color-primary);
}
.alert-error {
background: #fee2e2; /* red-100 */
color: var(--color-error);
}Coexisting with modern systems
You don't have to ban color names entirely. A healthy division of labour:
Named colors — keep for
- Demos, teaching, quick experiments
- Devtools tinkering
- Educational material explaining underlying hues before introducing Tailwind/Radix semantics
Modern palettes + tokens — use for
- Real products and design systems
- Themable components
- Anything with light/dark mode, accessibility requirements, or rebrand potential
ColorR can help in both directions: find tomato in the CSS Named Colors collection → inspect its hex/HSL/OKLCH → use "nearest" Tailwind/Radix/Open Color hues to replace it systematically. Or use CSS names in educational material and map them to your modern palette.
So… is it time to retire tomato?
Not entirely — but it's time to demote it.
Keep tomato, gold, teal for
- Tutorials and blog posts
- Quick prototypes
- Playful one-offs
For production UI, use instead
- Structured palettes (Tailwind, Radix, Material, Open Color)
- Design tokens as your primary source of truth
- CSS named colors as historical and pedagogical tools, not infrastructure
That way, you respect the web's history — and ship UIs that stand up to modern expectations of consistency, accessibility and theming.