What Are Tokens in Web Design? A Practical Guide

What are tokens in web design? They are named, reusable design decisions—such as a color role, spacing step, or type size—that let a team refer to an intention instead of repeating an unexplained value. A token can connect a design file to styles in a website, but the connection needs a clear naming model and an implementation path; creating a variable alone does not automatically synchronize every tool.

Think of a token as a named design decision

A raw value tells you what something is numerically: a color such as #FACC15, a spacing value such as 16px, or a type size such as 14px. A token adds a human-readable name that tells the team why the value exists or where it belongs. The Design Tokens Community Group format describes a token as information associated with a human-readable name, with at least a name and value.

For example, yellow-500 can name a palette step. A semantic token such as surface/notice can refer to that palette value for a warning or notice surface. A component then uses the semantic role rather than hard-coding a yellow. If the visual language changes, the role can point to a different value without changing the component’s meaning.

Move from palette values to useful tokens

Start with a small scale of raw values, then add semantic names only where they help people make consistent choices. Common roles include page background, raised surface, primary text, muted text, border, focus ring, primary action, and status. These are examples, not a universal schema; name roles around the decisions your product actually repeats.

The supplied image shows palette swatches with light, primary, bright, and dark color labels. It illustrates a set of raw color choices, not a complete token map or an accessibility review. The next step is to decide which interface role each color serves and whether that role changes across themes.

A practical chain might be green-700 → action/primary → primary button background. The first name describes a color scale position; the second describes a semantic role; the component uses the role. Keep these levels separate when the same color may serve different purposes, or when one purpose may need a different color in another theme.

Use tokens for consistency without hiding context

Tokens make repeated decisions easier to update and review. If several pages use the same action color, changing the semantic action token gives the team one named place to inspect. If a component requires a special value, avoid adding a token just to replace one literal; create one when the value carries a reusable decision or supports a context the system needs to handle.

Names should help a designer or developer choose correctly. A name like blue-600 may be useful for a raw scale, but does not explain whether the color belongs to a link, a selected state, or a border. Names like text/link or border/strong communicate a role, provided those roles are defined in documentation and used consistently.

Do not mistake tokens for a full design system. Tokens cover named values and relationships. Components define interface structure and behavior; guidance explains when to use those components; accessibility testing checks whether the result works for people. A tokenized color palette by itself does not make a page accessible or ensure its contrasts are sufficient.

Map Figma variables to web styles deliberately

Figma variables are reusable values that can be applied to design properties. Figma explains that aliasing one variable to another can implement design tokens, and that collections and modes organize values for different contexts such as light and dark themes. A useful Figma setup might keep raw palette variables in one group and semantic roles in another, with aliases connecting the two.

In CSS, custom properties provide named values that can be reused in stylesheets and changed through the cascade. For instance, a site may define --color-action-primary and reference it in a button style. That is an implementation choice; a Figma variable does not become a CSS custom property unless your team exports, maps, or re-creates it through a tooling workflow.

The Design Tokens Community Group published its 2025.10 format module as a stable exchange specification for sharing tokens between tools. It is a Community Group specification, not a W3C Standard. Treat it as an interoperability format, not a promise that two products will interpret every extension or workflow in exactly the same way. Check the current support and mapping rules of each tool you use.

Use modes for real design contexts

A mode is useful when the same semantic decision needs different values under a context such as light or dark theme. Keep the semantic name stable—such as surface/default—and provide an appropriate value for each mode. The component can continue using the same role while the design context changes.

Figma also describes using modes for language and device-size contexts. Those options can help teams explore how a design changes, but they do not replace responsive rules in the website or translation review. For color themes, inspect the actual foreground and background combinations in every mode, including hover, disabled, and focus states. Do not infer accessibility from the token name or from a palette swatch.

Avoid multiplying modes for every possible situation. Add a context when the product has a real need and the team can explain which frame, page, or component selects it. If a value should not vary with a theme, keep it fixed rather than adding a mode for symmetry.

Keep the token set small enough to maintain

Start by listing repeated decisions visible across a few representative screens. Group related values, document what each semantic role means, and point to the components that use it. Ask a developer to confirm that names can map cleanly to the codebase and that the update path is understood before expanding the set.

Review whether a proposed token is actually reused, whether its name describes its role, and whether changing it would have a predictable impact. Remove stale aliases and unused values through an intentional migration: rename, update consumers, and then remove the old name. Blindly replacing values can cause a subtle theme or state regression.

EmviUI’s Figma UI kit includes variables and reusable components, so it can give a team concrete examples to inspect or adapt. It does not decide the names or code mapping for a particular product. For the Figma-specific use of tokens, see our guide to design tokens in Figma. For handoff into a coded interface, read our Figma-to-Tailwind workflow; for structuring the screen before styling, see our Figma and wireframes guide.

Sources and further reading

• W3C Design Tokens Community Group: Format Module 2025.10
• Figma Help: variables, collections, and modes
• Figma Help: modes for variables
• MDN: CSS custom properties