Design tokens solve a real problem: the same brand blue living as a different hex in three codebases until a rebrand turns into a week of find-and-replace. Style Dictionary is the tool that kills that problem. You define each token once, and it generates the CSS variable, the Swift constant, and the Android resource from a single source. I've migrated a product from hand-copied colors to a token pipeline, and the first rebrand after took twenty minutes instead of three days. That's the whole pitch.
If tokens are new to you, start with the broader picture in the design tokens Figma to code guide. This one goes deeper on the specific tool most teams end up reaching for, and where it fits between Figma and your codebase.
TL;DR: Style Dictionary is an open-source build step that takes your design tokens from one JSON source and generates them for every platform: CSS variables, iOS Swift, Android XML. Figma variables feed it through an export, ideally in the DTCG token format (a W3C Community Group spec, not a ratified W3C standard). The tooling is easy. Naming discipline is what makes or breaks it.
What Does Style Dictionary Actually Do?
Style Dictionary is an open-source build step. Its input is a set of token files, usually JSON. Its output is those same tokens in every format your platforms speak. One color/brand/primary value becomes a CSS custom property for web, a Swift constant for iOS, and an XML resource for Android, all generated, none hand-typed.
The magic word is transforms. A raw token might be #2563eb. A transform can turn that into rgb(), into a Swift UIColor, into an Android @color reference, whatever the target needs. You write the token once and configure how each platform should receive it. Change the source, run the build, and every platform moves together. No drift, no three-way copy-paste.
Where Does Figma Fit In?
Designers don't write JSON, and they shouldn't have to. Figma variables are where tokens are born. The connection to Style Dictionary is an export step: a plugin like Tokens Studio pushes your variables out to a JSON file, and it runs on any Figma plan. Figma also ships a Variables REST API, but there's a catch worth knowing before you architect around it: that endpoint needs a Full seat in an Enterprise organization, so on Professional or Organization plans it's simply unavailable and the plugin is your path. That file, ideally in the DTCG token format that reached its first stable version (v2025.10) in October 2025, becomes Style Dictionary's input. Worth flagging: this is a W3C Community Group specification, a Community Group Report rather than a ratified W3C standard, so treat it as stable-but-evolving.
So the pipeline reads left to right: a designer edits a variable in Figma, exports to JSON, and Style Dictionary transforms it into platform code. The quality of the output depends entirely on the discipline of the input. Name your Figma variables semantically, color/surface, spacing/md, radius/sm, and the generated code is clean. Name them blue-3-final and you inherit that mess in every codebase. The token structure you build in the step-by-step design system guide is what makes this stage painless.
Here's how one Figma variable lands on each platform once it runs through the build:
| Figma variable | CSS output | iOS (Swift) | Android (XML) |
|---|---|---|---|
color/brand/primary | --color-brand-primary | UIColor constant | @color resource |
spacing/md | --spacing-md | Swift constant | dimen resource |
radius/sm | --radius-sm | Swift constant | dimen resource |
One source value, three platform outputs, none of them hand-typed.
Why Get the Token Values Right First?
A pipeline only ships what you feed it, so the values matter as much as the tooling. Your spacing tokens should sit on a consistent scale, not arbitrary numbers, and our free spacing scale generator builds one you can paste straight in. Your type sizes should follow a ratio rather than guesswork, which is what the type scale calculator is for. Feed Style Dictionary a clean, systematic set of values and the output is a system. Feed it a pile of one-off numbers and you've just automated inconsistency.
Where Do Teams Trip Up?
Three snags come up again and again.
- Naming that leaks implementation. Tokens named after their value (
blue-500) instead of their role (color-action) can't survive a theme change. Name by intent. - Skipping the semantic layer. Reference base tokens through semantic ones, so
color-button-bgpoints atcolor-brand-primary. Then a rebrand changes one base value and cascades everywhere. - Treating the export as one-and-done. Figma variables change. If the export is a manual chore nobody remembers, the code drifts from the design again. Wire the export into a script so it stays honest.
One upside once the pipeline runs: point Style Dictionary at a TypeScript output and every token ships as a typed constant your editor autocompletes. The typed output pays off in daily work, too. Reference a token that doesn't exist and the compiler flags it before the component ever renders, so a renamed color-action-primary can't quietly rot half your buttons. That safety net is exactly why teams bother generating typed tokens instead of loose strings in the first place. Large systems generate thousands of them, and that used to drag type-checking down. Since TypeScript 7 (Project Corsa) reached GA in July 2026, the native Go compiler checks that generated surface roughly 10x faster, so a big token file no longer taxes the build. Coding Dunia's TypeScript 7 guide breaks down what actually changed.
Design tokens are also the cleanest thing you can hand a developer, which is why they sit at the heart of a good designer to developer handoff. Get the tokens right in Figma, let Style Dictionary do the translating, and the gap between what you designed and what ships mostly closes on its own. My take: the tooling is the easy part. The naming discipline is the whole game, and it's the part most teams shortchange.
