Design tokens in the W3C DTCG format store design decisions such as colours, spacing and type as platform-neutral JSON, with $value and $type per token and aliases in braces. The Design Tokens Community Group published its first stable version, 2025.10; tools convert the tokens into CSS, iOS and Android code.

Design Tokens (W3C DTCG)

Details
Full Name

Design Tokens in the format of the W3C Design Tokens Community Group (DTCG) — design decisions such as colours, spacing and type stored as tool-neutral data

Also known as

DTCG format, Design Tokens Format Module, .tokens.json

Core Concepts:

  • A token is a named design decision. Colour, spacing, font or duration is stored once, under a name, and every platform reads it from there.

  • Tokens are objects with $value and $type. The format is JSON. Types include color, dimension, fontFamily, fontWeight, duration, cubicBezier and number, plus composite types such as typography, shadow and border.

  • Groups give tokens a hierarchy. Nested objects group related tokens; the path through the groups forms the token’s name.

  • Aliases reference other tokens. A value written as {group.token} points to another token, so one change carries through every token that refers to it.

  • Descriptions travel with the data. $description documents a token where it is defined.

  • Data first, code later. Files use the extension .tokens.json. Tools such as Style Dictionary, Tokens Studio and Terrazzo turn them into CSS, iOS, Android or other outputs.

    Key Proponents

    Jina Anne, who coined the term "design tokens" with Jon Levine at Salesforce, formerly co-chair of the W3C Design Tokens Community Group and its chair emerita since 17 June 2026; Andy Bell credits her work on the Lightning Design System in "What are design tokens?" (2020); the editors of version 2025.10: Louis Chenais, Mike Kamminga, Kathleen McMahon, Drew Powers, Matthew Ström-Awn, Donna Vitan

When to Use:

  • Writing colour, spacing and type values as a file that design tools and code share

  • Setting up themes and modes (light, dark, brand variants) from one source

  • Handing design decisions to several platforms through a build tool such as Style Dictionary

  • As a format instruction when a generated "token file" comes back as CSS custom properties or ad-hoc JSON

Common Misunderstandings:

  • Equating tokens with CSS variables. Tokens are tool-neutral data. CSS custom properties are one output among many. In our prior test on 2026-10-28 the baselines returned exactly that: CSS custom properties or plain JSON. With the DTCG name, six of six runs wrote $value and $type, and four of six used alias references in braces. The bare "design tokens" resolves to design systems on all tiers.

  • Calling DTCG a W3C Recommendation. Version 2025.10 is a Final Community Group Report. It did not go through the W3C Recommendation track.

  • Assuming more tiers are always better. Aliases make it possible to stack layers of tokens. Each layer adds indirection that someone has to understand and maintain.

Criticism:

  • Too many layers turn tokens against their purpose. Shaunak Bhanarkar argues in "Design tokens: A double-edged sword in design systems" (UX Planet) that "Too many layers of abstraction can make tokens difficult to use." He describes how stacked layers, duplicate tokens and drifting names push teams back to hard-coded values.

Current Status:

  • The first stable version is out. Version 2025.10, published on 28 October 2025, is the first stable release. It has three modules: Format, Color and Resolver. The Color module supports modern colour spaces such as Display P3 and Oklch; the Resolver handles themes and modes. Style Dictionary, Tokens Studio and Terrazzo implement it. The training-data prior most likely serves the earlier drafts: they wrote a colour value as a hex string, while the 2025.10 Color module describes colours as objects with a colour space.