What are design tokens? A practical reference for 2026

On October 28, 2025, the W3C Design Tokens Community Group published version 2025.10 of its specification, the first release the group calls stable. After years of every tool inventing its own JSON shape, design tokens finally have a shared file format, and Figma, Style Dictionary, and Tokens Studio all point to it.

A design token is a named value, such as a color, a spacing step, a font size, or an animation duration, stored in a platform-neutral format so that design tools and code read the same thing. Tokens are usually organized in three tiers: primitives that hold raw values, semantic tokens that describe intent, and component tokens that tie intent to one part of the UI.

What counts as a design token?

Any value you would otherwise copy and paste is a candidate: hex codes, pixel values, font stacks, durations, easing curves, shadows. In the DTCG format, a JSON object with a $value property is a token, and its key is the name. Objects without $value are groups. A token can also carry $type, $description, $deprecated, and $extensions, and a missing $type is inherited from the parent group.

The spec defines seven basic types (color, dimension, fontFamily, fontWeight, duration, cubicBezier, number) and six composites (shadow, border, typography, gradient, transition, strokeStyle). A companion Color Module adds modern color spaces such as Display P3 and Oklch.

Not everything deserves a token. A one-off illustration color is content, not system.

The three tiers: primitive, semantic, component

Primitive tokens hold the raw palette and scales: color.blue.600, space.4, radius.2. Nobody should apply them directly to product UI.

Semantic tokens describe purpose: color.text.primary, color.background.action, color.border.danger. They alias primitives, and they are where modes live. In dark mode, color.text.primary points at a different primitive while the scale itself stays put.

Component tokens bind a semantic token to one component: button.primary.background aliases color.background.action. They are optional, and each one is another name to maintain.

A complete chain: button.primary.background points to {color.background.action}, which points to {color.blue.600}, which holds the color. Designers pick from the semantic layer, engineers consume it, and the primitive behind it can change without anyone touching a component.

The tier test

When a new value shows up in a design, run it through five questions before it becomes a token:

1. Is the value already in a primitive scale? If not, decide whether the scale lacks a step or the design is off-scale. Add primitives rarely.
2. Does it express a reusable purpose, such as a border on an invalid field? Reuse or create a semantic token.
3. Does it change by mode (light, dark, high contrast, brand)? Then it belongs at the semantic tier or above.
4. Must exactly one component change it independently of the semantic default? Only then create a component token, as an alias.
5. Can you name it without a hue or a size word? If not, it is probably still a primitive in disguise.

How should you name design tokens?

Nathan Curtis's 2020 article "Naming Tokens in Design Systems" splits names into four groups of levels: a namespace (system, theme, or domain), an object (component, element, or component group), a base (category, concept, property), and modifiers (variant, state, scale, mode). Most teams use a subset. Pick one order and lint it.

Three rules keep the table honest:

• Use groups (dots in the source file) and let the build tool add hyphens or camel case per platform. DTCG names can't contain {, }, or ., and can't start with $.
• Keep the mode out of the name. color.text.primary-dark is a second token pretending to be a mode.
• Keep state and purpose out of primitives. color.blue.600 should never become color.blue.hover.

Designers pick from the semantic layer, engineers consume it, and the primitive behind it can change without anyone touching a component.

What is the DTCG format, and is it a standard?

The 2025.10 release has three modules. The Format Module defines token files: $value is required, aliases use curly braces like {color.blue.600} and resolve to a whole token, and JSON Pointer references via $ref can reach inside composite values. Circular references are errors, groups can inherit with $extends, and files use .tokens or .tokens.json. The Color Module covers color spaces. The Resolver Module handles tokens that vary by context, with sets, modifiers such as theme with contexts like light and dark, and a resolutionOrder where later entries win.

It is not a W3C Standard: the spec's status section calls it a stable Final Community Group Report, not on the Standards Track. The group's announcement names Style Dictionary, Tokens Studio, and Terrazzo as reference implementations.

From token file to platform code

Three tools do most of the work in 2026:

• Figma variables store token values in design files. As of October 2026, Figma exports a collection's modes as JSON and imports mode files in the DTCG format, with Figma-specific data under com.figma extension keys.
• Tokens Studio is a Figma plugin that syncs token JSON with GitHub, GitLab, Bitbucket, and other providers. It can write the DTCG format and export themes to variable collections with modes (themes need a Pro license).
• Style Dictionary is the build step. It has supported DTCG since version 4, and 5.7.1 is current on npm as of October 2026. Its docs say full 2025.10 support is still in progress, so test the types you rely on.

If you are starting from nothing, write the semantic tier first. List the purposes your interface actually has (text, surfaces, borders, actions, feedback), name them, and only then build the primitive scale that feeds them. Teams that start with a 200-color palette end up with tokens nobody uses.

Where Pegasus fits

Pegasus shows design tokens working on two surfaces at once. The Figma library ships 470 design tokens as Figma variables, covering color, type, spacing, radius, and shadow, with light and dark modes. The React code reads the same tokens through its theme object, because one token source themes both. Component names, variant structure, and tokens match across Figma and code.

Every one of the 1,540 components comes in light and dark variants, and that shared token source is why retheming Pegasus to your brand is a token change rather than a redesign.

To learn tokens from a working system, inspect a component in Figma, note its variables, then find the same names in the code's theme. Pegasus Lite, the free subset of the components, is enough to try this.

FAQ

What is the difference between design tokens and CSS variables?

A CSS custom property is one output of a design token, not the token itself. The token lives in a platform-neutral file with a name, type, and value. A build tool such as Style Dictionary turns it into --color-text-primary for the web and native formats for iOS and Android.

Are Figma variables the same as design tokens?

Figma variables are Figma's storage for token values inside design files. They support aliases, modes, and per-platform code syntax, and as of October 2026 Figma imports and exports variable modes as DTCG-format JSON. They are not the whole system: text styles and shadows often live in Figma styles, and code still needs a build step.

Do I need component tokens?

Not at the start. Most products work well with primitives and semantic tokens alone. Add a component token when one component must change independently of the shared semantic value, such as a button background a brand wants to tune on its own. Make component tokens aliases of semantic tokens so they inherit mode changes.

Is the DTCG format an official W3C standard?

No. Version 2025.10, published October 28, 2025, is a Final Community Group Report that the Design Tokens Community Group calls stable, but it is not on the W3C Standards Track. Adoption is the real signal: Style Dictionary, Tokens Studio, and Terrazzo are reference implementations, and Figma's variable import expects DTCG JSON.

Sources

• Design Tokens Format Module 2025.10, Design Tokens Community Group (2025)
• Design Tokens Resolver Module 2025.10, Design Tokens Community Group (2025)
• Design Tokens specification reaches first stable version, W3C Design Tokens Community Group (2025)
• Naming Tokens in Design Systems, Nathan Curtis (2020)
• Modes for variables, Figma Help Center (2026)
• DTCG format support, Style Dictionary (2026)
• style-dictionary package, npm (2026)
• Export to Figma guide, Tokens Studio (2026)