Design Tokens in 2026: The W3C Format Finally Standardizing Cross-Platform Design

Design tokens have been a design systems buzzword for years, but until recently the actual file format underneath them was tool-specific fiction. Export tokens from Figma, export the same tokens from Tokens Studio, export them from a hand-rolled Style Dictionary config, and you’d get three different JSON shapes for the same color value. That changed on October 28, 2025, when the W3C Design Tokens Community Group shipped version 2025.10, the first stable release of a shared specification backed by more than 40 organizations, Adobe, Figma, Google, Microsoft, Shopify, and Salesforce among them.

If you’re still treating design tokens as “the JSON file our design tool happens to export,” here’s what the standard actually changes and whether adopting it is worth the migration.

What a token actually looked like before this

The core idea of a design token, a single named value for a color, a spacing unit, a font size, that both design tools and code can reference, was never controversial. What was broken was interoperability. A tool like Tokens Studio represented a color one way. Figma’s own variable export represented it another way. A team’s hand-maintained Style Dictionary config assumed a third shape. Moving tokens between any two of these meant writing a translation layer, and that translation layer broke every time one of the tools changed its export format.

// A rough sketch of the kind of shape mismatch this caused.
// Tool A's export
{ "color-blue-600": "#1D4ED8" }

// Tool B's export for the conceptually identical token
{
  "color": {
    "blue": { "600": { "value": "#1D4ED8", "type": "color" } }
  }
}

Neither shape is wrong. They’re just incompatible, and every team building a real multi-platform design system ended up writing custom import and export scripts to bridge between whatever their design tool produced and whatever their build pipeline expected.

What DTCG actually standardizes

The spec defines a common token shape: every token is an object with a required $value and $type, and tokens can reference other tokens by a dot-path alias instead of duplicating the raw value.

{
  "color": {
    "blue-600": { "$value": "#1D4ED8", "$type": "color" }
  },
  "button": {
    "primary-bg": { "$value": "{color.blue-600}", "$type": "color" }
  }
}

That alias syntax, {color.blue-600}, is doing more work than it looks like. It’s what makes a semantic token layer, a button’s background pointing at a base color rather than hardcoding the hex value again, portable between tools. Change color.blue-600 once and every token that references it updates, in any tool that reads the DTCG format, without a custom resolution step written per destination.

Where this actually shows up in your pipeline

The format change doesn’t replace Style Dictionary or a similar build tool, and it isn’t supposed to. Style Dictionary and Terrazzo both still do the actual work of transforming a token source file into platform-specific output: CSS custom properties for a web app, an asset catalog for iOS, XML resources for Android.

# Style Dictionary reading a DTCG-format source file
style-dictionary build --config tokens.config.js

/* Generated output: CSS custom properties from the same token source */
:root {
  --color-blue-600: #1D4ED8;
  --button-primary-bg: var(--color-blue-600);
}

What changed is the source file itself. Before, that source file was whatever shape your specific build tool expected, meaning a Figma plugin export usually needed a translation step before Style Dictionary could ingest it. Now Figma, Penpot, Sketch, and Tokens Studio can all export the same DTCG-shaped file, and Style Dictionary and Terrazzo can both read it directly. The translation layer that used to be custom, brittle glue code specific to your toolchain is increasingly just… not needed, because the tools on both ends agree on the file shape.

Migrating an existing token setup

If your tokens currently live in a tool-specific format, the migration is usually smaller than it sounds. The structural change is mechanical: wrap each token’s value in a $value key, add a $type, and convert any references to the dot-path alias syntax. Style Dictionary’s newer versions read the DTCG format directly, so for most teams this is a config update and a validation pass against the new schema rather than hand-editing every token file.

The part worth doing carefully is your semantic layer, if you have one. This is a good moment to audit whether your semantic tokens (button-primary-bg, text-error) actually alias to your base tokens the way you think they do, since the migration forces you to make every reference explicit in a format that’s easy to lint. A team that’s been carrying inconsistent or duplicated color values for a while tends to find a handful of them during this pass, the kind of drift that a broader design systems foundation is supposed to prevent but that accumulates anyway without tooling that actually enforces it.

Is it worth adopting now

The return scales directly with how many platforms have to stay visually consistent. A team shipping one web frontend gets a smaller win, mostly the basic discipline of naming values instead of hardcoding hex codes, which is worth doing regardless of file format. A team shipping the same brand across a web app, an iOS app, and an Android app is the case this format was built for: change a brand color once in a DTCG source file, and Style Dictionary can push that change into CSS, Swift, and Kotlin output without anyone touching three codebases by hand.

With Figma, Style Dictionary, and the major design tools now converging on one file shape instead of three, the case for treating your design tokens as a tool-agnostic source of truth, rather than an artifact of whichever design tool your team happens to use, is stronger than it’s been at any point since the concept became popular.