For years, a design system had two versions of the truth. One lived in Figma, where a color was a named swatch a designer could see. The other lived in the codebase, where the same color was a hex string a developer had typed by hand. They drifted apart the moment either side moved. A brand refresh meant a spreadsheet, a lot of find and replace, and a quiet prayer that nobody missed a screen.
That gap is what design tokens were always meant to close. In 2026 they finally do, and the reason is less glamorous than it sounds: the industry agreed on a file format. Once the format became boring, everything built on top of it got interesting.
What a design token actually is
A design token is a named design decision, stored as data instead of as a hard-coded value. Rather than writing #5A50CE in forty places, you name the decision once and reference the name everywhere.
In practice a token is a small piece of JSON:
{
"color": {
"brand": { "$value": "#5A50CE", "$type": "color" }
},
"space": {
"md": { "$value": "16px", "$type": "dimension" }
}
}Two things make this powerful. First, tokens can point at other tokens. A semantic token like button.background can alias color.brand, so changing the brand color updates every component that leans on it. Second, because the token is just data, a build step can translate it into whatever each platform needs: a CSS variable for the web, a Swift constant for iOS, an XML resource for Android. One decision, expressed everywhere, with no manual copying.
The thing that actually changed in 2025
Tokens are not new. What changed is that they stopped being a proprietary idea locked inside each tool. On October 28, 2025, the W3C Design Tokens Community Group shipped the first stable version of its Design Tokens Format Module, version 2025.10. More than twenty major organizations backed it, including Adobe, Google, Microsoft, Meta, and Figma.
A stable spec sounds like a footnote. It is the whole story. Before it, choosing a token tool meant partial lock-in, because every tool wrote its own JSON dialect. Now there is one agreed shape, built around a simple pair of keys, $value and $type, plus a recommended media type, application/design-tokens+json, and file extensions .tokens or .tokens.json. A file that follows the spec can move between tools without a translation layer.
The stable release also baked in things design system teams had been faking for years:
- Theming and multi-brand support, so light mode, dark mode, and separate brand variants live in one structured file instead of a pile of hand-managed copies.
- Modern color, with support for Display P3 and Oklch, aligned to CSS Color Module 4. Your tokens can finally describe the wide-gamut colors that modern screens can show.
- Real relationships between tokens, through aliases and inheritance, so the link between a primitive value and the semantic decision that uses it survives the trip into code.
The adoption numbers moved with the spec. In a zeroheight survey of around 300 practitioners, teams using design tokens jumped to 84 percent, up from 56 percent a year earlier. Tokens are now the default, not the exception.
Figma stops being a walled garden
The most practical shift for most teams is happening inside Figma. For a long time, getting variables out of Figma and into code meant a third-party plugin and a custom export script. Figma has now committed to native import and export of variables that conform to the W3C format.
The workflow this unlocks is refreshingly plain. A designer can export one variable mode or several at once as standards-compliant JSON. Importing works the same way in reverse: drop a token file into a collection, and Figma creates new variables where they are missing and updates existing ones in place rather than duplicating them. The file a designer hands off is the same file a developer builds from. No dialect, no converter, no drift.
Figma is not alone here. More than ten design tools already support or are implementing the standard, including Penpot, Sketch, Framer, Tokens Studio, Supernova, Knapsack, and zeroheight. The point of a shared format is that no single vendor owns your tokens. You can change tools without rewriting your design language.
The pipeline that ships tokens everywhere
A format is only useful if something turns it into real code. That job belongs to a token transformer, and the two names worth knowing are Style Dictionary 4, the open-source workhorse maintained by Amazon, and Terrazzo, the newer challenger. Both read DTCG JSON and emit platform-specific output.
A healthy 2026 pipeline looks like this:
- Designers author tokens in Figma Variables or Tokens Studio.
- The tokens are exported as DTCG JSON and stored in the repository as the source of truth.
- A build tool such as Style Dictionary transforms that JSON into CSS variables for the web, Swift for iOS, and XML for Android.
- Continuous integration runs the build on every change and opens a pull request with the regenerated files.
The output of that build is unremarkable, which is exactly the goal. From the JSON above, the web target produces:
:root {
--color-brand: #5A50CE;
--space-md: 16px;
}A designer nudges a value in Figma, and a reviewed pull request lands in the codebase a few minutes later. Design changes reach production without a single copy-paste, and every platform stays in step because they all read from the same file.
What tokens still will not fix
It would be dishonest to sell tokens as a cure-all. The format solves interoperability. It does not solve taste, and it does not solve governance.
The hardest part of a token system is still naming. A token called blue-500 tells you what a value is but not when to use it. A token called surface.raised tells you what it means but hides the value. Mature systems keep both layers: a primitive layer of raw values, and a semantic layer of decisions that reference them. Getting that split right is a design problem, not a tooling problem, and no spec will make the choice for you.
The other unglamorous truth is ownership. Once tokens flow automatically from design into production, a careless change ships just as fast as a careful one. Teams that succeed treat their token file like code: it has an owner, changes go through review, and there is a clear rule for who can add a new token versus who can only reference existing ones. The pipeline removes friction, so the discipline has to come from people.
How to start this quarter
You do not need a platform team to begin. You need a first honest inventory.
- Pick one surface, such as buttons or typography, and list every raw value it uses today.
- Name those values as primitive tokens, then add a thin semantic layer on top for the decisions that matter.
- Store the tokens as DTCG JSON in your repository, not in a design tool you might leave.
- Wire up Style Dictionary to generate CSS variables from that file, and delete the hard-coded values it replaces.
- Only then connect Figma, so design and code read from the same source instead of two copies.
Start narrow and let it prove itself. A token system earns trust one surface at a time, and the moment a brand tweak ships to every screen from a single edited value, nobody on the team will want to go back.
The quiet win
The design tokens story in 2026 is not a flashy new feature. It is a boring, shared file format that a whole industry finally agreed to speak. Boring is the point. When the format stops being a debate, teams get to spend their attention on the design instead of the plumbing. After years of two competing versions of the truth, design systems and code are reading from the same page at last.