What is the Design Tokens Community Group?
The DTCG writes the format design tools exchange tokens in. Here is what the 2025.10 release actually standardises, and what it deliberately leaves open.
Before a shared format existed, every tool that handled design tokens invented its own. A colour defined in one application could not be read by another without somebody writing a translation script, so teams re-entered the same values across web, iOS and Android and watched them drift apart the moment one copy changed.
The Design Tokens Community Group exists to remove that translation step. It is an open group hosted by the W3C whose output is a vendor-neutral file format for exchanging tokens between tools, and its stated aim is to provide technology that products and design tools can rely on for sharing parts of a design system at scale. What it standardises is narrow and worth being precise about: the shape of the file, not how anybody works.
The DTCG standardises the file, not the workflow
The specification says what a valid token file looks like. It does not say how many tiers your system should have, what to name anything, when to introduce a theme, or which tool should own the source of truth.
That restraint is deliberate and it is why adoption worked. A format that also prescribed an architecture would have had to pick winners among design systems that had already made different, defensible choices. Two spec-valid token files can describe completely different systems, and both are correct. The layering you put on top is your decision, and the format stays out of it.
A Community Group publishes reports, not W3C Standards
This distinction gets flattened in most write-ups, and it matters practically. The DTCG is a W3C Community Group, which is a different thing from a W3C Standards Track working group. W3C notes that Community Groups are proposed and run by the community, and that they do not necessarily represent the views of W3C membership or staff.
So the group publishes technical reports rather than W3C Recommendations. In practice that has cost the format very little, because adoption by the tools people actually use is what gives a format authority. What it means for you is simpler: treat the spec as the industry's shared target rather than as a compliance obligation, and check what your tooling actually implements rather than assuming a version number guarantees it.
Membership is open to anyone at no cost, and the work happens in public repositories rather than behind a member wall.
2025.10 splits the spec into Format, Color and Resolver
The stable release published on 28 October 2025 is not one document. It is three modules, each covering a separate concern, which lets a tool implement what is relevant to it without committing to all three at once.
| Module | Covers |
|---|---|
| Format | How tokens and groups are structured in a file |
| Color | How colour values are represented and exchanged |
| Resolver | How references are resolved across files and contexts |
Splitting the specification this way is what makes partial support meaningful. A build tool that reads token files needs Format. A design tool working across colour spaces needs Color as well. Saying a product "supports DTCG" without naming modules describes very little.
The Format module defines tokens, groups and aliases
Three rules from the Format module carry most of the weight in day-to-day use.
Every property the specification defines is prefixed with a dollar sign. $value,
$type, $description. The prefix keeps the format's own metadata unambiguous inside a
JSON structure that also contains your token names.
An object with a $value is a token. An object without one is a group. The
distinction is strict, which is what lets a parser walk an arbitrary tree without being
told where the tokens are.
A token can reference another by its dot path in curly braces, written
{color.blue.500}, with JSON Pointer syntax also supported. A curly-brace reference
targets a complete token rather than a property inside one. Alongside that, $type set on
a group is inherited by the tokens inside it, so a file of fifty dimensions declares its
type once.
{
"space": {
"$type": "dimension",
"md": { "$value": { "value": 16, "unit": "px" } },
"card-gap": { "$value": "{space.md}" }
}
}
Adopting the spec, or helping write it
If you are choosing tooling, the useful question is not whether a product mentions the
DTCG but which module and which revision it implements, and whether the file it writes is
the file it reads. DAES Token Manager stores tokens in the DTCG 2025.10 shape natively
rather than converting on export, so there is no intermediate format between the plugin
and the JSON in your repository. Style Dictionary
reads $value and $type directly on the build side.
If you want to shape the specification instead, joining costs nothing: create a W3C account, join the group, and agree to the contributor licence before making substantive contributions. The work runs on public issues and pull requests, so reading the open threads for a week tells you more about where the format is heading than any summary will.
What the spec does not reach is everything after the file. It defines how a decision travels between tools, not how a team sees the component that decision produced, which is the separate problem LookBook addresses.
Is DTCG 2025.10 final, or will it change again?
Does using the DTCG format lock me into particular tools?
Should a design team join the group?
The Design Tokens Community Group at W3C is the primary source for the group's scope and membership, and the 2025.10 technical reports are where the three modules are published.
