Skip to main content

03

4 min

Semantic tokens

Hard-coded values are how design systems rot. A hex code pasted into forty components looks fine on day one. On day two, the brand color changes, and now you are hunting through forty files hoping you caught them all.

Semantic tokens fix this by adding a layer of meaning between the raw value and the component. Nothing references a color directly. Everything references a purpose.

There are three tiers, and each one only points downward.

A primitive is a raw value with a name. blue-600 is #2563eb. That's all it is — a fact, not a decision. You define primitives once and you rarely touch them again.

A semantic token is a decision. primary points to blue-600. Now primarymeans something: it's the color your product leads with. When the brand shifts, you change what primary points to — once — and every decision built on it follows.

A component token is where the system meets the interface. button-bg points to primary. The button never knows what blue it is. It only knows it wants the primary color, and the system answers.

Follow the chain: blue-600primary button-bg → the button on screen. Change the primitive, and the change flows down every link that depends on it. You edit one value; the system updates itself.

Primitiveblue-600
Semanticprimary
Componentbutton-bg

Try the presets, then change the color yourself. Notice what you are not doing: you are never touching the button. You change a value near the top, and the result arrives at the bottom on its own. That gap — between the value and the component — is the entire point. It's what lets a system grow without turning into a find-and-replace job.