DTCG reaches first stable spec (2025.10): theming, modern c…

The W3C Design Tokens Community Group published 2025.10 as the first stable specification edition. After more than half a decade of working drafts and incremental proposals, design systems teams finally have a normative text they can build pipelines and tooling against without expecting a breaking change next quarter. That stability is the headline — for everyone shipping multi-brand or multi-platform design systems, it's the difference between an experiment and a foundation.

"The specification unlocks interoperability across design tools and code," said Kaelig Deloumeau-Prigent, co-chair of the Design Tokens Community Group. "Design systems teams can now maintain one source of truth that works everywhere — from design to production code across iOS, Android, and web."

TL;DR

First production-ready stable edition of the DTCG spec.
Vendor-neutral JSON format for design tokens.
Modern color — Display P3, OKLCH, and CSS Color Module 4-aligned spaces.
Multi-brand themes — light/dark, accessibility variants, brand skins without duplication.
Aliases and references — first-class relationships, not stringly-typed conventions.
Cross-platform — one canonical file feeds web, iOS, Android, Flutter, and the rest.
Tool support at launch: Style Dictionary, Tokens Studio, Penpot, Figma, Sketch, Framer, and others.

What "stable" means here

The DTCG ran on a series of working drafts since 2019. Each draft moved the proposal forward, but tools that implemented one draft sometimes broke when the next landed. 2025.10 is the first edition where:

The schema of token JSON ($value, $type, $description) is frozen.
The type system (color, dimension, font, shadow, gradient, etc.) has agreed-upon shapes.
Aliasing semantics (the {group.token} reference syntax) is normative, not "implementation-defined".
Composite tokens (typography, border, shadow as combinations of primitive tokens) have a documented expansion process.

A stable foundation lets vendors implement once and stop worrying about churn.

Theming and multi-brand

The biggest practical use case. A typical SaaS in 2026 ships:

Light and dark modes by default.
Accessibility variants (high contrast, reduced motion) for WCAG compliance.
Brand skins for white-label customers or internal product lines.

Before DTCG stabilized, each variant typically meant a copy of the entire token tree with a few overrides — fragile and easy to drift. The 2025.10 spec formalizes a theming layer:

{
  "$themes": {
    "light": { "selectedTokenSets": ["base", "light"] },
    "dark": { "selectedTokenSets": ["base", "dark"] },
    "highContrast": { "selectedTokenSets": ["base", "high-contrast"] }
  }
}

A theme is a selection of token sets, not a duplicate. The "base" set defines structure (spacing scales, font stacks, semantic role names); the "light" / "dark" / "high-contrast" sets supply only the values that differ. Tooling expands the active theme into a flat token map at build time.

Modern color

Earlier drafts were vague about color spaces, leading to interop bugs where tool A treated a hex value as sRGB and tool B treated it as Display P3. 2025.10 nails it down:

`color` tokens specify both the value and the color space explicitly.
OKLCH, Display P3, sRGB, and other CSS Color Module 4 spaces are all first-class.
Conversions between spaces are defined when consumers don't support the source space.

{
  "brand": {
    "primary": {
      "$value": { "colorSpace": "oklch", "components": [0.70, 0.22, 142] },
      "$type": "color"
    }
  }
}

P3-capable displays render the saturated value; sRGB-only displays get the documented fallback. No more silent gamut clamping.

Aliases and references

A design token rarely stands alone. button.background references color.brand.primary; field.padding references spacing.medium. 2025.10 makes these references first-class:

{
  "color": {
    "brand": { "primary": { "$value": "#22c55e", "$type": "color" } }
  },
  "button": {
    "background": { "$value": "{color.brand.primary}", "$type": "color" }
  }
}

Tools resolve the reference at build time, but the graph of references is preserved through the toolchain so that:

Documentation generators can show "where is this token used?".
Refactoring tools can rename a primitive token and update every reference.
Visual editors can offer "swap to a related token" suggestions.

Composite tokens

typography, shadow, border, and gradient are composite types — collections of primitive tokens. The 2025.10 spec documents the expansion:

{
  "heading-1": {
    "$type": "typography",
    "$value": {
      "fontFamily": "{font.family.display}",
      "fontSize": { "value": 32, "unit": "px" },
      "fontWeight": 500,
      "lineHeight": 1.1,
      "letterSpacing": "-0.02em"
    }
  }
}

Style Dictionary, Tokens Studio, Penpot, and other consumers can flatten the composite into platform-specific output:

CSS — font: 500 32px/1.1 var(--font-family-display).
iOS — a UIFont instance with the right traits.
Android — a TextStyle resource.

Cross-platform output

The promise of "one source of truth" is now real:

Web — CSS variables, Tailwind config, JS modules.
iOS — Swift constants, asset catalogs.
Android — XML resources, Compose theme objects.
Flutter — Dart constants and ThemeData.

Style Dictionary's transforms (covered in the Style Dictionary 5.4 release post) produce platform-specific outputs from the same canonical JSON.

Ecosystem at launch

The announcement called out implementations across the tool spectrum:

Style Dictionary — Amazon-maintained transformer, the workhorse for code generation.
Tokens Studio — design-tool plugin and platform for managing tokens at scale.
Penpot — open-source design tool with native DTCG support (covered in the Tokens Studio × Penpot post).
Figma, Sketch, Framer — exporters, importers, or native variable systems aligned with the spec.

"A stable design token specification is an essential, open foundation for sharing design across teams, tools, and frameworks," said Nathan Curtis.

Migration from older drafts

If you've been running on a 2024-era working draft, the 2025.10 migration is mostly mechanical:

`$value` / `$type` are the canonical key names; older drafts that used value / type (no prefix) need a one-pass renamer.
Color tokens without an explicit color space pick up the default ("sRGB"); audit if you intended P3.
Composite token shapes stabilized — verify your typography / shadow tokens match the documented schema.

Most tools provide automated migrations; check your specific implementation before manual edits.

Worked example: a brand-themable button

A concrete shape for how multi-brand theming looks in practice:

{
  "$themes": {
    "acme": { "selectedTokenSets": ["primitives", "semantics", "acme-brand"] },
    "zenith": { "selectedTokenSets": ["primitives", "semantics", "zenith-brand"] }
  },
  "primitives": {
    "color": {
      "neutral": {
        "100": { "$value": { "colorSpace": "oklch", "components": [0.97, 0.005, 145] }, "$type": "color" },
        "900": { "$value": { "colorSpace": "oklch", "components": [0.20, 0.01, 145] }, "$type": "color" }
      }
    }
  },
  "semantics": {
    "color": {
      "button-text": { "$value": "{primitives.color.neutral.100}", "$type": "color" }
    }
  },
  "acme-brand": {
    "color": {
      "button-bg": { "$value": { "colorSpace": "oklch", "components": [0.70, 0.22, 142] }, "$type": "color" }
    }
  },
  "zenith-brand": {
    "color": {
      "button-bg": { "$value": { "colorSpace": "oklch", "components": [0.65, 0.18, 285] }, "$type": "color" }
    }
  }
}

The button consumes semantics.color.button-text and acme-brand.color.button-bg. Switch the active theme to zenith and the same component renders with Zenith's purple. No duplicated component, no parallel CSS file, no theme-aware prop drilling.

Why this took so long

Token formats have been a recurring topic since the early 2010s — Salesforce's Theo, Amazon's Style Dictionary, Tokens Studio's various iterations, and dozens of in-house formats. Each was useful in isolation but locked teams into the tool that produced it. The DTCG was founded in 2019 to fix that, and the path to a stable spec involved:

Aligning existing implementations on shared semantics for color, dimension, typography.
Resolving disputes about reference syntax and aliasing.
Defining composite types rigorously enough that two tools produce the same output.
Coordinating with W3C CSS Working Group on color spaces.
Convincing vendors to converge on the format.

Six years is a long time, but the alternative — every tool defining its own format and shipping bridges to every other tool — is worse. With 2025.10 stable, the alternative finally goes away.

Where this connects

The Style Dictionary 5.4 release post covers the most-used codegen tool's alignment with 2025.10. The Tokens Studio × Penpot post covers what stable DTCG looks like inside an open-source design tool. Together, the three posts trace the spec from normative text to design tool to code pipeline.

References

Technical report: designtokens.org/tr/2025.10/
Announcement: W3C Design Tokens Community Group
Issues & proposals: design-tokens/community-group on GitHub

Source / further reading: W3C Design Tokens Community Group

DTCG reaches first stable spec (2025.10): theming, modern color, interoperability