Most brands live in two places that never talk to each other. A polished guidelines deck describes the brand in prose. A sprawl of production code holds the brand hard-coded, slightly wrong, and different on every page. The gap between those two is where brands quietly decay.
Design tokens close that gap. A token is a named value, like color.primary, space.4, or radius.lg. Jina Anne coined the term at Salesforce around 2014, while building the Lightning Design System, to solve exactly this: a design decision made once, then recreated by hand in different languages on different platforms, drifting a little each time. Naming the value turns it from a decision someone made into a contract the system relies on. Your tokens are your brand's API.
The API metaphor is precise. A token name is the public interface. The raw value behind it is the implementation. Components call the interface and never touch the implementation, so you can change a brand color the same way you change the body of a function: callers keep working, and the new value flows everywhere they reference it.
A contract, not a suggestion
Guidelines give advice. Use this blue, roughly this spacing, this typeface for headings. People interpret advice, and interpretation drifts. By the fortieth page your one blue has split into four, your spacing scale has grown a few off-by-a-pixel cousins, and nobody can say which is correct.
You don't interpret a token. You reference it. When every heading points at type.display instead of a literal font size, one definition of a display heading exists, and the brand stops being something you remember to apply.
Three tiers, one chain of references
Mature systems don't keep a flat list of tokens. They use three tiers, and the wiring between them is the whole trick.
- Primitive tokens hold raw values with no meaning attached:
base-color-green-5,base-size-4. This is the palette, not the brand. - Semantic tokens assign intent:
color.bg.default,color.text.primary,border.default. These point at primitives. This is the layer you design against. - Component tokens scope a decision to one part:
button.primary.bg.hover. These point at semantic tokens.
Each tier aliases the one below it. Components reference semantic tokens, semantic tokens reference primitives, and a single raw value sits at the bottom of every chain.
Change a brand from blue to teal. You edit one primitive, base-color-teal-5, and repoint the primary palette at it. The semantic token color.bg.brand already aliases that primitive, so it updates with no edit. The component token button.primary.bg aliases color.bg.brand, so the button updates too. Every page that renders a primary button follows from one edited value. You never opened a component file.
GitHub's Primer is a clean example to read. It splits tokens into exactly these tiers: base tokens like base-color-green-5, functional tokens like fgColor-default and bgColor-default, and component tokens like button-primary-bgColor-hover. Shopify's Polaris ships its set as the @shopify/polaris-tokens npm package and names semantic tokens by a formula, --p-color-element-role-variant-state, so --p-color-bg-surface-hover reads as background, surface, hover at a glance.
The theming payoff
Semantic tokens are what turn dark mode from a rewrite into a config swap. The mechanism is the indirection. Your components reference color.text.primary, never a hex. In light mode that semantic token aliases a near-black primitive; in dark mode the same token aliases a near-white one. Components never change. You ship one extra mapping, and a whole second theme appears.
Primer states the rule plainly: when a user switches to dark mode, the base color a functional token references changes, but the token name stays the same. That only works if no component ever hard-coded the value. One literal #24292f in a button defeats the entire theme for that button.
Material 3 pushes the same idea to an extreme worth studying. It takes a single source color, derives five key colors, expands each into a tonal palette of thirteen tones numbered 0 to 100, then assigns tones to 26 named color roles that components consume. The algorithm pairs a dark surface role with a light text role so every pairing clears a 3:1 contrast minimum automatically. The brand is one input. Everything downstream is derived and named.
A format the whole industry agreed on
This used to be a private convention per team. Now it has a spec. The W3C Design Tokens Community Group, with more than twenty editors and authors from Adobe, Amazon, Google, Microsoft, Meta, Figma, Salesforce, Shopify, and others, shipped the first stable version of its format on October 28, 2025. The format is plain JSON: each token carries a $value and a $type, and one token can alias another, so color.button.background can reference color.primary and inherit whatever it resolves to. The three-tier chain above is expressible directly in the file.
Tooling turns the file into real code. Style Dictionary, the build system Danny Banks open-sourced at Amazon, reads your tokens and emits CSS custom properties, Swift, Android XML, and more from one source; the Tokens Studio team took over its maintenance in 2023. Figma variables have become the place most teams keep tokens now, though they don't sync to code on their own. You still wire up the pipeline that crosses the gap.
What the hard-coded version costs
Skip the token layer and the failure mode is predictable. In a large codebase with many hands, one developer writes #1264a3, another writes #1366a8, a third writes rgb(18, 100, 163), all reaching for the same blue. None of them are wrong locally, and together they are a brand that no longer has one blue. A rebrand then becomes an audit of dozens of files with plenty of room for a value to slip through, instead of one edit at the source.
Tokens you can hand to a machine
Iterant learns a brand once from its URL. We read the real colors, the type ramp, the spacing rhythm, and the radii, capture them as a token set, and point every section we generate at semantic tokens instead of literal values. A hundred drafted pages then share one definition of the brand and can't drift apart, because there is nothing to drift toward.
The hard part is choosing tokens a system can apply without a designer in the loop. Too few and the brand looks generic. Too many and nothing composes. The durable set runs smaller than people expect: a tight color ramp, two or three type roles, one spacing scale, a couple of radii, and an elevation step. Get those right and they recombine into on-brand layouts you haven't built yet.
The first time a founder changed their accent color and watched every draft page follow, they stopped thinking of us as a generator. We were their brand, with a dial on it.
Design systems lead
Iterant proposes the pages; you review and approve before anything ships. The token set is what makes that review fast, because you check the brand once at the source rather than page by page. The guidelines deck describes your brand to people. The token set describes it to everything else. Define it once, reference it everywhere, and your brand stops decaying one hard-coded value at a time.