Design Token Generator
Export any color as a W3C Design Tokens Community Group (DTCG) compliant JSON token. Drop straight into Style Dictionary, Tokens Studio for Figma, or any modern multi-platform pipeline.
- W3C DTCG JSON schema with $value, $type, $description metadata
- Pantone reference attached as $extensions metadata
- Style Dictionary 4.x compatible out of the box
- Multi-platform: emits HEX, RGB, HSL, Lab, and CMYK alongside
Direct answer
{ "$type": "color", "$value": "#…" } with extension metadata for Pantone reference, RGB, HSL, and Lab. Paste it into your Style Dictionary or Tokens Studio source files and the rest of your pipeline takes over.Design Token Generator
#6366F1
Design Tokens (JSON)
{
"name": "Pantone 7455 C",
"hex": "#6366F1",
"rgb": {
"r": 99,
"g": 102,
"b": 241
},
"cmyk": {
"c": 59,
"m": 58,
"y": 0,
"k": 5
},
"hsl": {
"h": 239,
"s": 84,
"l": 67
},
"lab": {
"l": 50.1,
"a": 38.69,
"b": -70.49
},
"pantone": {
"code": "Pantone 7455 C",
"finish": "coated",
"family": "blue"
}
}When this saves you time
Real workflows where design token generator replaces tedious manual work or an in-app subscription tool.
Bootstrap a token file from scratch
Move from Tailwind config to tokens
Round-trip with Tokens Studio
Encode Pantone reference alongside HEX
Scale to a portfolio of brands
Document an existing color in legal-friendly form
How it works
The methodology — every transformation documented so the output is reproducible.
Parse the input color
Whatever form you type — HEX, RGB, HSL, named CSS color — is normalized to a canonical HEX (#RRGGBB) and a sRGB triple for downstream conversions.
Compute alternate representations
We derive HSL, OKLCH, Lab (D65 illuminant), CMYK (sRGB → CMYK uncalibrated), and the nearest Pantone PMS reference with ΔE2000 distance.
Wrap in W3C DTCG JSON
The token uses $value for the HEX, $type:'color' for the schema constraint, and $description for the human label. Alternate spaces sit under $extensions.com.pantonetools as non-normative metadata.
Validate against Style Dictionary
Output is tested against Style Dictionary 4.x parsing rules. Drop the file into config.tokens[] and run the build — no schema errors, no manual cleanup.
Worked examples
| Input | Result | Notes |
|---|---|---|
| #2563EB · token: color.brand.primary | { "color": { "brand": { "primary": { "$type": "color", "$value": "#2563EB" } } } } | Minimal DTCG-compliant token. Style Dictionary picks it up as a color reference. |
| #10B981 · with $description | { "$type": "color", "$value": "#10B981", "$description": "Success state" } | Description travels with the token and surfaces in generated docs. |
| #0F172A · with Pantone metadata | { "$type": "color", "$value": "#0F172A", "$extensions": { "com.pantonetools": { "pantone": "Black 6 C", "deltaE": 2.3 } } } | Vendor extensions ride along — ignored by Style Dictionary, consumed by custom transforms. |
| Multiple tokens (DTCG group) | { "color": { "primary": { "$type": "color", "$value": "#2563EB" }, "secondary": { "$type": "color", "$value": "#10B981" } } } | Nest related tokens under a shared group. $type lifts to the parent if omitted on children. |
Common mistakes to avoid
Mixing the old Style Dictionary format with DTCG
Putting non-color metadata in $value
Forgetting to escape token references
Versioning tokens loosely
Frequently Asked Questions
Why design tokens matter
A design token is a named variable that captures a design decision — “the brand primary is #2563EB” — in a machine-readable form. Stored once, consumed everywhere: Tailwind config, CSS variables, iOS Color resources, Android color XML, Figma styles, marketing email templates. The token is the source of truth; every platform is a derivative.
Before the W3C DTCG effort, every team rolled its own format: Salesforce used Theo, Amazon used Style Dictionary with custom JSON, Atlassian had its own shape. DTCG consolidates these into a single schema that downstream tooling can read. As of 2024, Style Dictionary 4, Tokens Studio, and Specify all consume it natively — making this the safe bet for new design systems.
The pipeline from token to platform
A typical setup: token JSON lives in a Git repo, a CI job runs Style Dictionary on every commit, and the output (CSS variables, Tailwind config, iOS Colors.xcassets, Android colors.xml) is published as packages or copied into downstream repos. Designers edit the JSON via Tokens Studio in Figma; engineers edit the JSON directly. Both sides see the same diff.
The "$extensions" bag is where the format earns its keep: you can attach print specs (Pantone PMS, CMYK), platform hints (iOS dynamic system colors), or analytics metadata (usage frequency from your design tool) without breaking the schema. Tools that don't understand the extension ignore it.
From single token to full system
This generator emits one token at a time — useful when adding a new color to an existing system. For a full palette of tokens, start with the palette generator or Tailwind palette generator and export the result as DTCG. Validate text/background pairs through the contrast checker before freezing them as semantic tokens (color.text.primary, color.surface.subtle).