How to export Figma variables to Tailwind (v4 @theme or v3 config)

There are three ways to export Figma variables to Tailwind. You can export each mode as JSON from the Variables tab and turn it into CSS with a small build step. You can run an export plugin that writes Tailwind output directly, such as Tailwind Helper for a v4 @theme block. Or, if a plugin generated your variables in the first place, you can use its built-in export. Whichever route you take, the goal on the code side is the same: primitives in Tailwind's theme, semantic tokens as CSS variables that switch with dark mode.

This is the code-bound direction. If you're going the other way, from a Tailwind palette into Figma, that's a separate job.

Before you export: get the structure right

Export quality depends almost entirely on how the variables are organized. Three checks:

1. Primitives in one collection, one mode. brand/600, neutral/900, space/4.
2. Semantic tokens in a second collection with Light and Dark modes, each value an alias to a primitive. Our variable modes setup guide covers this.
3. Names that survive the trip. Slashes become hyphens in CSS custom properties, so text/primary turns into --color-text-primary once it lands in Tailwind's color namespace. Avoid spaces and capitals. You can also set a code syntax name on each variable in Edit variables so developers see the code name in Figma (Figma).

What you're exporting to

It helps to know the target first. In Tailwind v4, the theme lives in CSS. A setup that keeps aliases and dark mode working looks like this:

@import "tailwindcss";

@custom-variant dark (&:where([data-theme=dark], [data-theme=dark] *));

@theme {
  --color-brand-600: #4f46e5;
  --color-brand-400: #818cf8;
  --color-neutral-50: #fafafa;
  --color-neutral-950: #0a0a0a;
}

:root {
  --surface: var(--color-neutral-50);
  --text-primary: var(--color-neutral-950);
  --action-primary: var(--color-brand-600);
}

[data-theme=dark] {
  --surface: var(--color-neutral-950);
  --text-primary: var(--color-neutral-50);
  --action-primary: var(--color-brand-400);
}

@theme inline {
  --color-surface: var(--surface);
  --color-text-primary: var(--text-primary);
  --color-action-primary: var(--action-primary);
}

Your primitives collection becomes the @theme block. Each semantic mode becomes one selector: the default mode on :root, the Dark mode on [data-theme=dark]. The @theme inline block turns the semantic variables into utilities like bg-surface and text-action-primary. Tailwind's theme docs recommend inline when a theme variable points at another variable, and its dark mode docs show the @custom-variant line for a data attribute.

On Tailwind v3, or a v4 project still using a JavaScript config, the same semantic variables go into tailwind.config.js as colors: { surface: 'var(--surface)' }. Tailwind v4 can still load that file with the @config directive, which its directives docs list as a compatibility feature for v3.

Route 1: native JSON export plus a build step

Figma's help center documents exporting variables without a plugin (Modes for variables):

• Right-click a mode in a collection and choose Export mode to get one JSON file.
• Right-click the collection itself and choose Export modes to export every mode.

You then need something that turns JSON into the CSS above. Options, from least to most setup:

• A short script in your repo that reads each file and writes the @theme and mode selectors. For a small system it stays short, and it's the easiest option to understand.
• Style Dictionary, an open-source build tool that turns token files into CSS, JS and platform formats. It's worth it once you also ship to iOS or Android.

Good for: teams with a developer who's happy to own a script, and anyone who wants no plugin in the chain.

Watch for: the export gives you files, not a sync. Someone has to run it after each change. Figma lists the REST API for variables, which you'd need to automate this, only on Enterprise (plans and features).

Route 2: an export plugin

These write code directly from your collections. Details are from each plugin's Figma Community listing as of October 25, 2026.

Tailwind Helper is the most Tailwind-specific. Its listing says it exports any collection to Tailwind v4 (@theme block) or v3 (:root plus config JSON), in OKLCH or HEX, and can skip Tailwind's defaults so only your custom values come out. It also works in reverse, reading CSS custom properties and adding them to Figma as extra modes. It's new (released February 2026) with a small user base, so test it on a copy.

variables2css has 29,001 users and converts collections to CSS, Tailwind, JSON and several other formats. You can pick specific modes, include all themes, choose HEX, RGB or HSL and px or rem, and decide how aliases are written. Its last listing update dates from November 2024.

Export Variables by Ease Studio has 19,529 users and exports variables to CSS and Tailwind, among other formats, with HEX, RGBA and HSL options. The listing says the plugin will stay free, and points teams that want GitHub sync and automatic pull requests to its separate Ease Studio beta.

Good for: designers who hand off without a developer writing a script.

Watch for: how each plugin writes aliases. Some resolve them to raw values, which breaks dark mode switching in code. Check that a semantic token comes out as var(--color-brand-600), not #4f46e5.

Route 3: export from the generator that made the variables

If a plugin generated your system, its own export already knows the structure.

• Supa Design Tokens lists Tailwind, CSS and JSON among its export formats. Its store lists one-time licenses between $90 and $650.
• Kigen exports variables and styles to CSS, JS and JSON (no Tailwind-specific output on the listing). Its listing says everything is currently free.
• Huekit is our plugin. We export the variables we generate as JSON or a Tailwind config, so the primitives, semantic layer and Light and Dark modes go to code with the structure we built them in. See huekit.io for what each plan includes.

Good for: systems that started in a generator and haven't drifted far from it.

The three routes compared

Keeping Figma and code in step

Pick one direction and stick to it. If design owns the tokens, the flow is: change variables in Figma, export, commit the file, and let a pull request show which values moved. Don't let developers edit the generated CSS by hand; change it in Figma and export again.

FAQ

Can I export Figma variables without a plugin?

Yes. In the Variables tab, right-click a mode and choose Export mode, or right-click a collection and choose Export modes. You get JSON, which you then convert to CSS or a Tailwind config.

How do I export Figma variables to a Tailwind v4 theme?

Put primitives in an @theme block, semantic tokens in :root and a dark selector, and map them into Tailwind with @theme inline. A plugin like Tailwind Helper writes the @theme block for you.

Does exporting keep light and dark modes?

Native export gives one JSON file per mode. Most export plugins let you include all modes. In CSS, each mode becomes its own selector over the same variable names.

Can I get a tailwind.config.js from Figma variables?

Yes. Tailwind Helper's listing mentions v3 output with config JSON, and Huekit can export a Tailwind config. On v4 you can load a legacy config with @config, though the CSS @theme approach is the current default.

Can I sync Figma variables to GitHub automatically?

Not natively unless you're on Enterprise, where the REST API for variables is available. Otherwise it's a manual export and commit, or a third-party service.

Do one export today

Export the Dark mode of your semantic collection, open the file, and check whether its values are aliases or raw colors. That one check tells you which route will keep your dark mode working in code.