One palette, roles that scale.
Semantic tokens keep component intent stable while the underlying colors evolve across a product, campaign, or theme.
Palette → semantic system
Design Token Generator
Turn raw palette colors into stable semantic roles for backgrounds, surfaces, actions, text, muted content, and borders. Reassign any role and every preview and export updates immediately.
Semantic roles describe intent, not a fixed shade. Components can reference
--color-primary instead of a literal blue, so the palette can change later without rewriting every component.Live context
Preview the semantic theme
This sample makes role changes visible immediately. It is a design preview, not a substitute for testing every real component and state.
Northstar
Muted helper text and a semantic border.
Production handoff
Export semantic tokens
The four outputs use the same resolved role values. Names stay semantic so components do not need to know which raw palette index currently supplies a role.
CSS variablesReady for
:rootJSONSimple semantic color object
SCSS variablesOne variable per semantic role
JavaScript / TypeScriptES module object usable by JS or TS
Name colors by purpose
A raw palette says which colors exist. Semantic tokens say what those colors do. primary can mean the main interactive emphasis, surface can mean cards and panels, and muted can mean secondary content. Components then depend on intent instead of a particular HEX value.
This separation is especially useful when a brand refresh, dark theme, seasonal campaign, or accessibility revision changes the palette but the interface structure stays the same.
Reuse is not a mistake
Eight semantic roles do not require eight unique colors. A small palette might use one light color for both background and surface, or one neutral for muted content and borders. What matters is whether each role remains visually and functionally clear in the components that use it.
Conversely, a large raw palette should not force every shade into the UI. Assign only the colors that have a repeatable purpose.
Change tokens, not every component
With semantic variables, a button can use var(--color-primary), a card can use var(--color-surface), and body copy can use var(--color-text). A theme change updates those definitions in one place rather than searching the codebase for literal color values.
For larger systems, teams often add component-specific or state tokens on top of these foundational roles. This generator intentionally stops at a compact semantic layer instead of inventing hundreds of tokens.
Token names do not guarantee readable combinations
The live preview checks a few common text pairings at 4.5:1 and flags failures, but that is only a quick signal. Real products also need focus states, disabled states, charts, icons, error messaging, interactive boundaries, and large-text rules tested in context.
Use the Palette Accessibility Matrix for pairwise planning and the Contrast Checker for exact foreground/background decisions. A semantic role system makes those fixes easier to apply consistently.