Figma variables changed how design systems handle theming, and if you haven't adopted them yet, you're probably working harder than you need to. We updated our entire template library to use variables last year, and the difference in maintenance time was immediate. One toggle switches a component from light to dark. One number change updates spacing across fifty screens. This figma variables tutorial covers what you need to know to get started.
If you're still relying only on color styles and manual overrides, this post is for you. We'll walk through the four variable types, how modes replace the old duplication hack for themes, and the practical difference between variables and the styles they partially replace.
What are Figma variables and why did they replace styles for theming?
Figma variables are reusable values that can change depending on context, unlike static styles that stay fixed. A color variable can hold one hex code in light mode and another in dark mode. A number variable can define padding that scales up for desktop and down for mobile. Styles only store one value, so supporting two themes meant duplicating every style and manually swapping them. Variables collapse that into a single source of truth.
We used to maintain two full color libraries for our templates: one light, one dark. Every update had to happen twice. With variables, we define the semantic names once, like "background-primary" or "text-default," and let modes handle the actual values. It's faster, less error-prone, and easier for developers to read in Dev Mode.
String, number, color, and boolean: the four variable types
Figma offers four variable types, and each solves a specific design system problem. Understanding all four prevents the common mistake of using color variables for jobs that number or boolean variables handle better. Choosing the right type early makes your system easier to maintain and clearer for developers reading your files in Dev Mode.
| Variable type | What it stores | Common use case |
| Color | Hex, RGB, or HSL values | Backgrounds, text, borders, fills |
| Number | Any numeric value | Spacing, sizing, border radius, grid gaps |
| String | Text content | Button labels, empty states, locale strings |
| Boolean | True or false | Toggle visibility, conditional layers |
Color variables are the most obvious starting point, and most teams adopt them first. Number variables are the hidden powerhouse: they let you build spacing systems that developers can reference directly. String variables are newer and especially useful for localization or CMS-connected designs. Boolean variables control whether layers appear, which is perfect for component variants that differ by more than just color.
We use all four in our SaaS templates. A single component set can scale from compact to spacious, light to dark, and English to another language, all without duplicating frames.
How do modes work for light and dark themes?
Modes are the feature that makes variables feel magical. You define a set of values for each mode, light, dark, compact, spacious, brand A, brand B, and Figma swaps the entire set with one dropdown selection. The variable names stay the same; only the values behind them change.
Here's how we set it up. First, create a variable collection for your semantic colors: "background-primary," "text-default," "border-subtle." Then define a "Light" mode with your light theme values and a "Dark" mode with your dark theme values. Apply the variables to your components. Now, changing the mode on any frame instantly repaints every component inside it.
This replaces the old workflow of duplicating components and maintaining two libraries. It also means you can preview both themes on the same page by placing one frame in light mode and another in dark mode. For teams shipping templates, this is a huge quality check: we can verify both themes side by side without copying a single layer.
What is the difference between variables and styles in Figma?
Variables and styles overlap, but they are not the same tool. Styles describe appearance: this text is 16px Inter in charcoal. Variables store raw values: the number 16, the color #333333, the string "Submit." Styles can reference variables, which is the pattern we recommend, but variables cannot reference styles.
The practical difference is control. A text style fixes font family, weight, size, line height, and letter spacing together. A number variable only controls size, letting you mix and match with different font families or weights. For design systems that need strict consistency, styles still matter. For systems that need flexibility, especially multi-brand or multi-theme systems, variables are the better foundation.
Our current workflow is to define variables for all raw values, then build styles on top of them. The variables become the single source of truth. The styles become the convenient presets. If you're building a design system from scratch, start with variables. If you're retrofitting an existing system, you can gradually swap style values for variable references without rebuilding everything.
How do you build a simple themed component with variables?
Start small. Pick one component, like a primary button, and create variables for its background color, text color, border radius, and horizontal padding. Name them semantically: "button-primary-bg" rather than "blue-500." Semantic naming is what makes theming possible, because the same variable name can mean blue in one mode and green in another.
Next, build the button using those variables. Apply "button-primary-bg" to the fill, "button-primary-text" to the label, and "button-padding-x" to the internal Auto Layout spacing. Once the button works, create a second mode in your collection and assign different values. Toggle between modes on the frame and watch the button update instantly.
From there, expand to your full component library. Navigation bars, cards, form inputs, and tables all follow the same pattern. The upfront work of setting up variables pays off when you add a third mode, a client white-label, or a seasonal theme. For more on structuring the components themselves, our guide on how to create a design system in Figma covers the component architecture that variables plug into.
Variables are the foundation of scalable design systems
Figma variables aren't a feature you adopt once and forget. They're a new way of thinking about design data. The teams that get the most value from them treat variables as the contract between design and code: designers maintain the semantic names, developers map those names to tokens, and the actual values live in one place.
If you're building templates that other teams will customize, like the ones in our template marketplace, variables are almost required. They let buyers switch themes without breaking components. They let us push updates that propagate across every screen. And they make handoff cleaner because developers can read exact variable names in Dev Mode.
Start with color and number variables. Add modes for light and dark. Build one component the right way, then scale. That's the workflow that worked for us, and it's the one we recommend.
Frequently asked questions
Can you use variables with existing styles?
Yes. Figma lets you bind style properties to variables, which means you can retrofit an existing design system without rebuilding every component. Update your text style's size to reference a number variable, or your fill style to reference a color variable. The style becomes a preset that pulls from the variable's value.
How many modes can a Figma file have?
A variable collection can have up to 40 modes on paid Figma plans. For most design systems, four to six modes cover every need: light, dark, compact, spacious, and maybe one or two brand variants. If you hit the limit, you can split themes across multiple collections.
Do variables work with Figma's dev mode?
Yes, and this is one of their biggest advantages. Developers can see the variable name, value, and mode directly in Dev Mode, which makes the handoff to code much clearer. Variable names often map one-to-one with CSS custom properties or design tokens in code, so the translation is straightforward.
