What is the DTCG JSON token standard and why should it be followed?
A neutral token format allows design, code, and build tools to read the same file without being locked into any company.
DTCG JSON is a standardized token format issued by the W3C community group. This format uses JSON with dollar-sign-prefixed properties like $value and $type, allowing all design tools and build tools to read a file. It should be followed as this is the standard that the entire industry agrees upon, enabling tokens to pass through multiple platforms without being locked to a single company. The first stable version is 2025.10, and many major tools like Style Dictionary, Tokens Studio, and Figma have supported it to varying degrees.
- token needs to go through multiple tools or platforms
- want to retain the option to change tools later
- following the standard from the beginning is cheaper than converting formats later
- only a small web product, one stack, one tool (less critical, but still advisable to follow)
DTCG JSON is a neutral token format issued by the Design Tokens Community Group, a community group under W3C (the global web standards organization). The simple goal is to create a common standard so that design tools, build tools, and the code running the product can all read the same token file without needing to translate back and forth. The first stable version is named 2025.10, and many popular tools have supported it to different extents.
What does DTCG JSON look like?
Technically, a DTCG JSON file is a plain JSON file, nothing special except for the naming conventions of the properties. Each token requires two mandatory properties: $value (real value) and $type (style, for example color, dimension, fontFamily). Additionally, you can add $description to note the purpose, $extensions to expand according to individual needs, and $deprecated to mark tokens that are no longer in use.
It is important to understand clearly: DTCG only standardizes the file format, it does not dictate how you should organize or name tokens. The strategy of tiering tokens into primitive, semantic, and component is something that the design and technical teams must develop themselves.
Why this is a worthy choice
The core reason is neutrality. When tokens are stored in DTCG format, you are not dependent on a single tool. If you use Tokens Studio today and want to switch to another tool tomorrow, the token file remains readable. If you only have a website today but later add an iOS or Android app, the file is still a valid starting point.
The second reason is the convergence of the industry. Style Dictionary, Tokens Studio, Figma, and many other tools are gradually standardizing around DTCG. Aligning with the industry today will save conversion costs later. New technical teams joining the project will also read tokens faster, as the conventions will be familiar.
When necessary, when less urgent
Should follow DTCG immediately: Tokens need to pass through multiple tools (from design to code), across various platforms (web, iOS, Android), or the team plans to change tools in the near future. This is also a good choice when starting a new project because compliance costs from the beginning are almost zero.
Less critical: A small product, only web, just one stack, a single tool from start to finish. But even in this case, it is still advisable to follow. This is the standard that the entire industry agrees upon, and the cost of following from the beginning is much lower than converting formats after having hundreds of tokens.
Common errors when applying
- Confusing DTCG as a construction tool: DTCG is merely a file input format. To output CSS variables, UIColor, or dp and sp for Android, you still need a separate construction tool like Style Dictionary to mediate.
- Mix old formats and DTCG formats within the same project: This creates two sources of truth, making maintenance difficult and easily causing conflicts when reading tools.
- Expecting that following standards means having a good system: DTCG addresses formatting issues, not strategic issues. Organizing tokens by layer, naming consistently, and deciding the scope of each token remains the responsibility of the design and technical teams.
Need to understand how far
Following a neutral standard from the beginning is the least costly technical decision that also provides the most long-term protection. Tokens are long-term assets, so they must endure multiple tool changes and platform expansions without needing to be rebuilt from scratch. You do not need to understand the entire technical specification of DTCG, but you should know that this is where the industry is heading, and getting on board early is always cheaper than joining late.
Decision checklist
Topic: What is a neutral DTCG JSON token and why should you follow it. Sinh Vũ guide, sinhvu.com
Tick each item that applies or that you can already answer, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Design Tokens Community Group, W3C (high). First stable release DTCG 2025.10 (high). designtokens.org FAQ (high). Style Dictionary, supporting DTCG (high). Practical experience from Sinh Vũ Studio.
Frequently asked questions
How does DTCG JSON differ from the current way Figma saves tokens?
Figma has its own token format in Variables and in plugins. DTCG JSON is a neutral format, not belonging to Figma or any company. If you only use Figma from start to finish, the two formats may appear similar on the surface. However, when tokens need to go outside of Figma, such as into code or iOS, the DTCG format is what build tools like Style Dictionary can reliably read.
According to the DTCG standard, can the token automatically generate CSS and Swift?
No. DTCG only standardizes the token file format, not the export tool. You still need a build tool like Style Dictionary to read the DTCG file and export it to CSS variables for the web, UIColor for iOS, or sp and dp values for Android. DTCG is the common standard at the input stage, while the output still needs to be configured for each platform.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.