Introduction
TypeScript toolkit for validating and linting DTCG design tokens.
Open Design Tokens checks design token files against the Design Tokens Format Module 2025.10 and the Color Module 2025.10, then lets you layer your own policies on top with a configurable linter.
It is built for the places where token files move between people and tools: CI on a pull request, a build step in a design-system repo, an editor integration, or a service that accepts uploads.
Status
Beta. The validator is feature-complete for the 2025.10 specifications and tested against the spec text, and the public API is settled in shape. Versions stay on 0.x until the toolkit has seen real-world use; see versioning for what that guarantees.
What you get
Validator
Every rule the specification defines, with stable issue codes and precise paths. Nothing configurable, nothing vendor-specific.
Linter
Twelve configurable rules, a recommended preset, and a small API for writing your own.
CLI
dtcg-lint validates then lints, with pretty, JSON, and GitHub-annotation output.
Types
Every token and value type, generic over $type, with narrowing helpers.
Design principles
- The spec is the spec. The validator reports what the normative text says, with errors for MUST violations and warnings where the spec says MAY or SHOULD. Where spec examples contradict the spec's own rules, the rules win and the examples are documented as known spec issues.
- Policy is separate. Name lengths, naming styles, required descriptions: those are lint rules you configure, never validator behaviour.
- Hostile input is normal input. Token files are untrusted. There is no code evaluation, nesting is bounded, references never leave the document, and diagnostics are escaped. See security.
- No runtime dependencies. The published package depends on nothing.
Try it
The playground runs the same code in your browser, with a loadable example for every rule.
Get help
Ask questions in Q&A and share ideas in Ideas on GitHub Discussions. Report bugs and spec mismatches as issues.