Tokens Studio: Design Tokens from Figma, Step by Step
Tokens Studio is a Figma plugin for creating design tokens and syncing them with GitHub or GitLab. What it does, how to set it up, and which plans exist.
What is a design token, and why does it matter here?
A design token is a named value: color.background.primary instead of #1A73E8. If the color changes, you change the token, not every screen. To understand how these names are layered, read token architecture.
Tokens Studio handles the middle step: tokens start in Figma, where the designer works, and reach the code without copying values by hand.
How does it work inside?
The plugin organizes tokens into three pieces:
- Tokens: each individual value, with a name and a type.
- Token sets: containers of tokens, for example
base,brand, ordark-mode. The documentation describes them as the no-code version of a JSON file. Each set needs a unique name, and a slash in the name (brands/berry) creates a folder in the tree. - Sync: a provider, such as GitHub or GitLab, where the JSON files are stored.
Each set can be enabled, disabled, or marked as a source. An enabled set makes its tokens available to apply, reference and export; a disabled set is ignored; a source set only supplies values for references. If two enabled sets have a token with the same name, the one lower in the list wins. That rule, similar to a cascade of defaults and overrides, is the basis of theming. Themes (combinations of sets applied together, such as light and dark) are a paid feature.
Names use dots to create hierarchy (color.text.secondary), and groups form a tree both in the plugin and in the code files. Each name must be unique within its set. Token names cannot contain the characters {, }, or $. The documentation also warns that names are often transformed on their way to code (changes of case, flattened groups) and can collide with each other, so think about how they will end up.
A semantic token (for example color.action.primary) can point to a palette token. That reference is what lets you change a theme by editing one layer, not every value in the interface.
How do you set up GitHub?
The official documentation describes these steps (Tokens Studio: GitHub sync):
- Create a repository and check “Add a README file”. The plugin cannot sync to an empty repository. It can be public or private.
- Generate a personal access token. A classic token needs the
reposcope; a fine-grained token needs Contents set to read and write. With read-only access you can view tokens but not create or edit them. - In Figma, open the plugin’s Settings page, choose “Add new” under sync providers, and select GitHub.
- Fill in the name, token, repository (
owner/repo), branch, and the path where the files will be stored. The base URL is only needed for an enterprise GitHub server. - Save, then push or pull to sync.
The path defines the shape of the output. With a folder (for example tokens), each set is saved as its own JSON file. With a file (for example tokens.json), all sets are combined into one, and the documentation warns that this limits how developers can work with theme information. Storing in a folder (multi-file sync) is a paid feature; if a collaborator does not have the Team plan, they will see those tokens as read-only. GitLab follows the same scheme, with the api scope on the token.
Which token format should you choose?
The plugin supports two: Tokens Studio’s legacy format, which is the default, and the W3C DTCG format, which prefixes properties with $ ($value, $type, $description). The documentation notes some conditions: DTCG defines token types the plugin does not support yet, and its output requires configuring Style Dictionary with SD-Transforms and convertToDTCG. In Git-synced repositories, each branch can use a different format. Reference: Tokens Studio: token format.
Which plans exist?
Prices change, so always check the official page (Tokens Studio: pricing). On November 7, 2026, the page showed:
| Plan | Price shown | What it includes, according to the page |
|---|---|---|
| Free | €0 | One editor, unlimited viewers, one project with one active branch. Access to the Studio platform, without the paid features of the Figma plugin. |
| Team | €39 per month, billed annually | One editor included (each extra editor costs €39 per month), unlimited viewers, 5 projects with 5 active branches each, 1 GB of assets, chat or Slack support, and all paid plugin features. |
| Organization | €499 per month, billed annually | 5 editors included (extra ones at €49 per month), unlimited projects and branches, 10 GB of assets, priority support. SSO, directory sync and audit export are paid add-ons. |
| Enterprise | Custom | Custom security and scale setups; contact sales. |
The page states that the legacy plans (Starter Plus, Pro and Essential) were folded into Team. The base price includes one editor on Team and five on Organization, and extra editors are billed separately. Studio offers a 14-day trial with no payment details required.
When should you NOT use it?
- If your team has no code workflow where the tokens will land. Without a destination, the plugin is just a well-organized palette.
- If you will sync to a single file and already have your own Style Dictionary pipeline, exporting JSON from another tool may be enough.
- If the team has not decided who owns the tokens. Without rules for changes, sets fill up with duplicate values. Solve that before picking any plugin; see design system governance.
Illustrative example
Illustrative example: a designer creates a base set with colors and spacing, and a dark-mode set that overrides only the surface colors; since the lower set wins, enabling both in that order is enough. She syncs with a repository whose tokens folder holds one file per set (a paid feature). The developer reads those JSON files with their build tool and generates CSS variables. When the designer changes the surface color in Figma and syncs, the change reaches the repository as a commit that can be reviewed, like any other code change.
If you already use AI to generate code from these values, read design tokens for agents. For the parity between design and code, see token parity.
Common mistakes
- Creating tokens with value-based names (
blue-2) instead of role-based names (color.action.primary). - Using an empty repository and then not understanding why the connection fails.
- Switching to the DTCG format without configuring Style Dictionary for the output.
- Editing the JSON by hand in the repository and then overwriting it from Figma.
- Assuming folder sync is free and discovering that a collaborator without a paid plan can only read the tokens.
- Assuming the tool replaces design decisions: a badly named token is still badly named.
What you can do tomorrow
- Open the plugin in a test file and create a
baseset with five colors and five spacing values. - Check the official documentation to see whether your code project already consumes token JSON or needs another step.
- Write a naming rule on a single page before you create more tokens.