Skip to content
PantoneTools
Design systems

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 a color and get a JSON object following the W3C Design Tokens Community Group (DTCG) format — { "$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

50
100
200
300
400
500
600
700
800
900
950

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.

New system

Bootstrap a token file from scratch

Drop your brand HEX and copy the DTCG block straight into tokens/color/brand.json. Style Dictionary will fan it out to CSS, Sass, Android XML, iOS Swift, and Tailwind in one build.
Migration

Move from Tailwind config to tokens

If your colors live in tailwind.config.ts today, run each one through the generator to emit DTCG tokens. Tokens become the source of truth; Tailwind, CSS variables, and Figma all derive from it.
Figma sync

Round-trip with Tokens Studio

Tokens Studio imports DTCG JSON directly. Generate the JSON here, paste into the plugin, and Figma styles update — single source of truth between design and code.
Print parity

Encode Pantone reference alongside HEX

The $extensions field carries the nearest Pantone PMS code and ΔE. Print teams pull from the same token file the web team uses, so brand color stays consistent on screen and on press.
Multi-brand

Scale to a portfolio of brands

Generate one token file per brand. A shared Style Dictionary build emits per-brand CSS variable bundles loaded dynamically, so the same components serve every brand without duplication.
Audit

Document an existing color in legal-friendly form

Some industries require formal color spec sheets (pharma, finance, government). The DTCG token doubles as a machine-readable spec — version it in Git and you have an auditable record.

How it works

The methodology — every transformation documented so the output is reproducible.

01

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.

02

Compute alternate representations

We derive HSL, OKLCH, Lab (D65 illuminant), CMYK (sRGB → CMYK uncalibrated), and the nearest Pantone PMS reference with ΔE2000 distance.

03

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.

04

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

InputResultNotes
#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

Pre-4.0 Style Dictionary used 'value' (no $). DTCG uses '$value'. Don't mix them in one file — set 'preview: dtcg' (or 'usesDtcg: true' depending on version) and use $ prefixes throughout.

Putting non-color metadata in $value

$value must match the $type. For a color token, $value is a color string (HEX, RGB function notation, or color()). Pantone codes and other metadata belong in $extensions.

Forgetting to escape token references

Style Dictionary references look like '{color.brand.primary}'. If you write '{color.brand.primary.value}' (old format) the new resolver fails. The generator emits the new short form.

Versioning tokens loosely

A token rename is a breaking change — every consumer that imports it needs to update. Treat the token file like a public API; use semver and changelog entries.

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).

Related tools

Design Token Generator — W3C DTCG JSON for... | PantoneTools