The Design Tokens Community Group (DTCG) announced on 28 October 2025 that the Design Tokens Specification has reached its first stable version, published as 2025.10. This release is published as a DTCG Technical Report / Candidate Recommendation and is explicitly described as considered stable, intended for production use and third‑party implementations.
For teams building design systems and cross‑platform token pipelines, 2025.10 formalizes conventions that many tooling projects and design teams have already been piloting. The stable spec brings a canonical format, clear conventions, and modules that make tokens usable across web, iOS, Android, Flutter and major design tools.
What the stable release means
The 2025.10 release is presented as the canonical, date‑based stable version for implementers and tools to target. Although the spec is a DTCG Technical Report / Candidate Recommendation (not a full W3C Recommendation), it is explicitly described as “considered stable” and intended to be implemented in production workflows.
Stability in this context means editors have agreed on core shapes, semantics and transport conventions so that different toolchains can interoperate without bespoke adapters. The DTCG encourages implementers to adopt 2025.10, report issues and suggest refinements via the community group and GitHub.
Practically, the stable release reduces fragmentation: vendors and open‑source projects can reference a single canonical spec when building importers, exporters and transforms, instead of relying on ad hoc token shapes. That clarity is already driving updates across tools, libraries and internal pipelines.
Core modules: Format, Color, and Resolver
The 2025.10 bundle includes three core modules published as final reports: the Format module, the Color module, and the Resolver module. Each module addresses a different layer of token authoring and delivery so implementers can adopt just the pieces they need or the full stack for end‑to‑end pipelines.
The Format module defines the token file shape, naming, reserved properties and composite types. The Color module documents structured color values with explicit colorSpace and components, supporting modern color spaces such as Display P3 and Oklch and aligning with the CSS Color Module Level 4. The Resolver module standardizes how multiple token files, themes and contexts are collated into a resolved token set.
Together these modules enable precise token semantics, from how a gradient or shadow is modeled to how themed overrides flatten into a final palette. For many teams, this modularity is the practical bridge between design intent and runtime values.
File format, token shape, and conventions
The spec standardizes token files as JSON and recommends the MIME type application/design-tokens+json with file extensions .tokens and .tokens.json. That explicit transport guidance helps service integrations, downloads, and HTTP delivery of token bundles across networks and CI pipelines.
Token shape follows a clear convention: tokens use $‑prefixed properties for metadata and semantics, for example $value and $type. Objects support composite types such as shadow, gradient and typography, and token names and structures are infinitely nestable so teams can map tokens to their preferred hierarchy.
The Format module includes normative examples and reserved patterns , including alias/reference syntax and the $value/$type pattern , that implementers must follow for conformance. Those rules reduce ambiguity when converting or transforming tokens between systems.
Resolver module and theming in practice
One of the big practical advances in 2025.10 is the Resolver module, which formalizes how multiple token files and theme contexts are combined. Resolvers act as entry files that describe inclusion, overrides and the rules to produce a final resolved token set for runtime or distribution.
The resolver concepts underpin theming and multi‑brand support, including modes, theme overrides and resolver‑driven flattening. Guides from projects like Terrazzo and Tokens Studio show typical patterns for modes, theme inheritance and resolver pipelines, making it easier for teams to implement consistent theming across platforms.
Because resolvers provide a standardized entry point for resolution, pipelines can produce consistent outputs for web, mobile and native toolchains , reducing the manual work of reconciling multiple source files into a single distributable token set.
Tooling, reference implementations, and ecosystem support
The stable release arrived accompanied by reference implementations and a growing set of tooling adapters. Style Dictionary, Tokens Studio, Terrazzo and other projects are cited as early implementers or adaptors, and community packages (for example style‑dictionary‑utils and tokens‑studio sd‑transforms) offer transforms and preprocessors for the DTCG format.
Several companies and projects quickly updated token pipelines to the DTCG format, and plugins for design tools now offer import/export workflows for the spec. Examples include Microsoft’s Figma Variables Import tool, TokensBrücke and direct support or documentation from Tokens Studio and Terrazzo.
The DTCG announcement lists more than 10 design tools and open‑source projects already supporting or implementing the spec, including Figma, Sketch, Framer, Penpot and others. This ecosystem momentum makes it practical for teams to adopt 2025.10 without locking into a single vendor.
Adoption strategy, migration guidance, and governance
Adopting the stable spec usually involves updating token pipelines, transforms and CI scripts. Tooling projects and maintainers provide migration notes and recommended transforms; for instance, Style Dictionary adapters and community transform libraries document how to convert legacy token formats to 2025.10.
The DTCG emphasizes community governance and ongoing development: editors continue to triage GitHub issues, host editor meetings and accept RFCs. Implementers are invited to report bugs, request clarifications and contribute to future revisions so the spec evolves based on real‑world usage.
Teams planning migration should check reference transforms, test resolver behavior with their theming patterns and verify color fidelity when moving to modern color spaces such as Display P3 or Oklch. The community writeups on Medium and project docs provide practical checklists and examples for common upgrade paths.
Why this matters for design systems
The 2025.10 stable release turns a long‑running interoperability goal into implementable reality. With a shared JSON format, clear conventions and resolver semantics, design teams can ship tokens that map predictably from Figma or other tools to production code across platforms.
Industry leaders and contributors celebrated the milestone. DTCG co‑chair Kaelig Deloumeau‑Prigent said that the specification “unlocks interoperability across design tools and code.” Other contributors, including Nathan Curtis, Mike Kamminga and Pablo Ruiz‑Múzquiz, praised the stable release for making token workflows more reliable and portable.
For designers and engineers, the practical upside is simpler pipelines, fewer bespoke mappings, and better cross‑platform consistency. For tool vendors and OSS maintainers, 2025.10 provides a solid target for adapters, importers and canonical transforms.
Getting started is straightforward: consult the canonical spec pages at designtokens.org/TR/2025.10 and the module docs, review reference implementations in the community repo, and use Tokens Studio or Terrazzo guides for resolver and theming patterns. Early adopters can rely on existing transforms in Style Dictionary and community transform libraries.
With broad participation from organizations such as Adobe, Google, Microsoft, Meta, Salesforce, Shopify, Figma and many open‑source projects, the 2025.10 release is both a technical milestone and a sign that the ecosystem is converging on common, production‑ready token semantics.
As teams evaluate the spec, expect continued refinement and incremental updates via the DTCG process. The stable 2025.10 baseline gives everyone a shared foundation to build on, while the open governance model lets practitioners influence what comes next.
Whether you manage a brand, a platform library or a multi‑product design system, the stable Design Tokens spec is now a practical tool to unify design and code across platforms and devices. Start with the Format and Resolver modules, test migrations with existing tooling, and contribute feedback to the DTCG as you adopt the specification.
The future of tokens looks more interoperable and more precise. With clear file conventions, modern color support and a resolver model for theming, 2025.10 is a turning point for design systems that need reliable, vendor‑neutral token exchange.