The Design Token Spec Is Finally Real. Now What?
DTCG 2025.10 is stable, Style Dictionary v4 supports it, and Figma Variables can export to it. Here's what actually changed and what still requires judgment.
The W3C Design Tokens Community Group published the 2025.10 format as a stable, versioned spec. Style Dictionary v4 ships native support for it. Figma Variables can export to it. The interoperability gap that made design token pipelines brittle — where every tool spoke a slightly different dialect — is largely closed. That's the fact. The question is what this actually changes for a team shipping a production token system, and what it still leaves entirely up to you.
What DTCG 2025.10 Actually Standardizes
The spec defines a JSON format for design tokens. That's the scope. It standardizes the shape of a token file so that tools can read and write the same format without custom transformation layers in between.
The key fields are:
$value— the token's value$type— what kind of value it is$description— human-readable documentation$extensions— tool-specific or team-specific metadata, namespaced to avoid collisions
The $ prefix on every field is intentional. It separates spec-defined keys from token group names, which means you can nest tokens freely without naming conflicts.
The spec defines 17 token types: color, dimension, fontFamily, fontWeight, duration, cubicBezier, number, string, boolean, strokeStyle, border, transition, shadow, gradient, typography, fontStyle. Each type has a defined value format. A dimension is a number with a unit suffix (px, rem, em). A shadow is an object with offsetX, offsetY, blur, spread, and color properties. The formats are specific enough to remove ambiguity, loose enough that they don't force implementation decisions.
This is what the spec does: it defines a container format. What goes in the container — the names, the structure, the values themselves — is still your problem.
What a DTCG Token File Looks Like
Here's a minimal, valid DTCG color token:
{
"color": {
"brand": {
"blue": {
"$value": "#2563eb",
"$type": "color",
"$description": "Primary brand blue — passes WCAG AA on white"
}
}
}
}
The token's resolved name is color.brand.blue, built by joining the group names with dots. The $type field tells any conforming tool how to interpret the value. The $description is optional but worth writing — it becomes documentation that travels with the token through every tool in the chain.
A more complete file with aliases looks like this:
{
"color": {
"brand": {
"blue-600": {
"$value": "#2563eb",
"$type": "color",
"$description": "Raw brand blue, 600 weight"
}
},
"interactive": {
"primary": {
"$value": "{color.brand.blue-600}",
"$type": "color",
"$description": "Default interactive color — buttons, links, focus rings"
}
}
}
}
The {color.brand.blue-600} syntax is DTCG's alias format. It's a reference, not a copy. Tools that understand DTCG resolve it at build time. This is what makes a layered token architecture work — raw values defined once, semantic aliases pointing at them, component tokens pointing at aliases.
What Style Dictionary v4 Does With It
Style Dictionary v4 treats DTCG format as a first-class input. You can point it at a DTCG-formatted token file and it will parse $value, $type, and $description natively, resolve aliases, and run them through your transformer pipeline.
The old Style Dictionary syntax used value and type without the $ prefix:
{
"color": {
"brand": {
"blue": {
"value": "#2563eb",
"type": "color"
}
}
}
}
The new DTCG syntax uses $value and $type. Style Dictionary v4 understands both, but new projects should use the DTCG format. The migration path for existing token files is mechanical — a find-and-replace on key names — but you want to do it deliberately rather than in the middle of a sprint.
The more significant change in v4 is $type inference. If you declare $type on a group rather than individual tokens, every token in that group inherits the type. For a file with 80 color tokens, that's a meaningful reduction in boilerplate:
{
"color": {
"$type": "color",
"brand": {
"blue-100": { "$value": "#dbeafe" },
"blue-200": { "$value": "#bfdbfe" },
"blue-600": { "$value": "#2563eb" },
"blue-900": { "$value": "#1e3a8a" }
}
}
}
Every token in that group is typed as color without repeating it. The transformer pipeline picks that up and handles CSS custom property output, platform-specific transforms, and anything else you configure.
The Workflow Change in 2026
If your toolchain is DTCG + Style Dictionary v4 + Figma Variables, you can now round-trip tokens between design and code with reasonable fidelity. Figma Variables can export to DTCG format. Style Dictionary consumes that file and generates platform outputs. If a designer renames a token in Figma, that change propagates through the pipeline on the next build.
This is genuinely new. Two years ago, the export formats were inconsistent enough that round-tripping required a custom transformation layer that you had to maintain yourself. Tokens Studio filled part of that gap with its own sync format, but you were still one tool update away from a broken pipeline.
The caveat is "if your toolchain is set up correctly." The spec doesn't configure your pipeline. You still need to define your Style Dictionary config, wire up your transforms, decide on output formats, and make sure Figma Variables export maps to the same token names your code references. The spec makes all of that more reliable once it's done. It doesn't do it for you.
What the Spec Does Not Solve
This is the part worth spending time on, because the DTCG announcement created some confusion about what the spec actually covers.
Naming is still your decision. The spec does not have an opinion about whether your primary button background token should be called color.interactive.primary, color.brand.blue, or --c-button-bg. Those are design decisions dressed up as naming decisions. The spec gives you a format for expressing whatever name you choose. The actual naming strategy — and the reasoning behind it — is something your team has to work out and document.
Governance is still your problem. Who can add tokens? What's the review process before a new alias token lands in the file? When does a deprecated token get removed, and how do you communicate that to consumers? The spec is silent on all of this. A token system without governance accumulates cruft. You end up with color.brand.blue, color.brand.blue-new, and color.brand.blue-v2 coexisting in the same file, all pointing at slightly different values, none of them documented.
The semantic layer architecture is a team decision. A four-layer architecture — raw values, primitives, aliases, component tokens — is a reasonable approach that a lot of teams converge on. But the spec doesn't prescribe it. You can have one layer or six. The tradeoffs between specificity and flexibility are real, and the right answer depends on your product's surface area and your team's capacity to maintain the system. The spec doesn't weigh in.
Platform-specific values require platform-specific judgment. DTCG has a dimension type that accepts px, rem, and em. It does not have a concept of iOS points or Android density-independent pixels. If you're shipping tokens to multiple native platforms, you still need a transformation layer that converts dimension values appropriately — and you need to decide whether a 16px spacing token should become 16pt on iOS or whether that relationship should be more nuanced. The spec standardizes how you express the input. The platform output is still an engineering decision.
Where This Leaves You
The DTCG spec closes the interoperability problem. That was a real problem — teams were maintaining custom sync scripts, writing transform logic to bridge Figma exports to Style Dictionary inputs, and losing work every time a tool updated its export format. That friction is largely gone now for teams using conforming tools.
What it doesn't close: the naming problem, the governance problem, and the "what should this token actually represent?" problem. Those are design decisions that require judgment about your product, your users, and how your design and engineering teams communicate. A stable JSON format is a prerequisite for solving them well. It is not the solution.
The practical state in mid-2026: if you haven't migrated your token files to DTCG format yet, do it. The tooling support is there, the migration is straightforward, and staying on a custom format means you're maintaining a transformation layer that you can now delete. If you have migrated, the next investment is in the layer the spec doesn't cover — clear naming conventions, a documented governance process, and explicit decisions about your semantic layer architecture.
The spec is infrastructure. What you build on it is still yours to design.