The W3C design token format changes what a token actually is

May 25, 2026

Pick a team that ships a design system. They use Style Dictionary to transform tokens into CSS and platform outputs. They use Figma Variables to let designers work with the same values. They have a build script that stitches the two together. All three tools call what they manage "tokens." None of them agree on what a token is. Style Dictionary treats a token as a named value with an optional metadata blob. Figma treats it as a variable scoped to a collection. The build script treats it as a string key in a JSON object. The W3C Design Token Community Group specification is trying to end that disagreement, and its answer turns out to say more about the nature of a token than most teams expected.

What the spec actually specifies

The DTCG format describes tokens as JSON objects. Each token has a $value, a $type, and optionally a $description and $extensions. The types are enumerated: color, dimension, font-family, font-weight, duration, cubic-bezier, number, string, composite, and gradient. At first glance this looks like a file format decision, the kind that only matters to the person writing the build config. It is actually a schema for intent. A dimension is not a number. It is a number with a unit and a semantic role in the layout system. A color is not a hex string. It is a value that color-management tools can interpret, convert, and validate without guessing. The spec formalizes what token-aware tools are allowed to assume, which changes what they are allowed to do.

Why types change the pipeline

When a token carries no type, every tool in the pipeline must infer it. Style Dictionary infers types from value shape: if it looks like a hex code, it must be a color. Figma infers from context: a variable used on a border-radius property must be a dimension. They often arrive at different answers for the same value, which forces teams to maintain override configs and per-platform maps that duplicate the original intent in a less readable form.

With an explicit $type, a transformer can skip that guessing step. Consider a token spacing.4 typed as dimension with a value of 16px. A DTCG-aware transformer targeting Android outputs 16dp. Targeting iOS, it outputs 16pt. Targeting CSS, it outputs 1rem against a 16px base. No per-platform override file. No conditional logic in the transform. The type carries enough information to make the decision correctly, and the output matches the platform's own unit semantics rather than a generic string.

Aliases become a first-class concept

The spec defines a reference syntax: {color.palette.red-500}. A token whose $value is a reference like this is an alias, and that alias is part of the token definition itself, not a feature of any particular tool. This matters because it moves the reference graph out of Style Dictionary's configuration and into the token data. A tool that consumes DTCG-format tokens is required to resolve that reference correctly. It cannot treat the value as an opaque string.

Previously, aliasing was a capability each tool offered on its own terms. Style Dictionary had its own reference syntax. Figma had its own concept of variable aliases. A token defined as an alias in one tool was invisible as an alias to any other tool reading the same file. The DTCG format makes the alias part of what the token is, which is the precondition for genuine roundtripping between tools that did not build each other.

Where it gets complicated

The spec does not define resolution order for aliases in the presence of modes. It does not specify how platform-specific overrides should be represented. It does not describe how to handle a token that means different things in light and dark contexts, or across device classes. Those are real requirements for any team running a design system at more than a basic scale, and the spec has no answers for them yet.

The $extensions field is the official escape hatch. A tool can store its own metadata there, which preserves spec compliance while adding the data it needs. The problem is that once each tool starts writing to $extensions, the interoperability benefit narrows. Tokens become readable by other tools but not fully interpretable by them. The same fragmentation that motivated the spec returns, just at a different level of the stack.

The teams who stand to gain the most from the DTCG format are the ones who have already built the fragmented pipeline: tokens in a repo, a separate sync script for the design tool, per-platform transform configs, and a release process that touches all three. The format does not eliminate that complexity. What it does is give it a common shape, so that a token defined in one place can be read by a tool that had no part in defining it. That is not the end of tool-specific concerns. It is the beginning of the kind of interoperability that makes it reasonable to change one piece of the pipeline without rebuilding all of it.