Figma to WordPress: How to Turn a Figma Design Into a Block Theme

Short answer: going from Figma to WordPress means translating four things. Figma variables become theme.json tokens. Figma components become blocks, patterns and template parts. Figma frames become block templates. Real page designs become the posts and pages you build with them. There is no single export button that does all four, so the work is a mapping exercise, and a clean Figma file makes it far easier.

This guide walks through that mapping for a block theme. Facts about Figma features come from the Figma Help Center. The WordPress side comes from the Theme Handbook. I have not tested any converter, plugin or tool for this post, and I do not recommend one. What follows is a workflow you can do by hand.

What “Figma to WordPress” actually means

People search for “Figma to WordPress” hoping for a magic step. Upload a design, get a theme. It is worth being honest about why that does not exist in a reliable form.

A Figma file describes how a design looks. A WordPress block theme describes how content is structured and styled so an editor can change it later. Those are different jobs. A designer places a heading at a position. A theme says “any heading, on any page, looks like this.” To get from one to the other, someone has to decide what is a token, what is a reusable piece, and what is one-off content.

That someone is you. The good news is that Figma has features that line up with the WordPress side, so the decisions are easier than they sound.

Figma	Block theme
Variables	theme.json settings (palette, sizes, spacing)
Text and color styles	theme.json styles for elements and blocks
Components and variants	Patterns, template parts, block styles
Auto layout frames	Group, Row and Stack blocks with layout settings
Page frames	Templates in the templates folder
Filled-in page designs	Posts and pages

If you know atomic design, this table will look familiar. I wrote the full mapping in Atomic Design in a WordPress Block Theme: From Tokens to Templates, and this guide is the Figma-specific version of it.

Step 0: get the Figma file ready

Most pain in a design handoff comes from a messy file, not from WordPress. Before anyone writes code, ask the designer for these things.

Variables for every repeated value. The Figma Help Center describes variables as a way to “account for different modes and themes,” with colors and numbers as the main types. If a color or a gap is a raw value on a layer, you will have to guess whether it is a token. If it is a variable, you know.

Components for every repeated piece. The Help Center says “Components are elements you can reuse across your designs.” A button, a card and a header should each be a component, not a copy-pasted group.

Auto layout on every frame. Auto layout makes a frame arrange its children by direction, spacing, padding and alignment. It is the closest thing Figma has to how CSS flex layout works, so it tells you how a section should behave when content changes.

Names that match your plan. Name variables by role, such as primary and contrast, not by value, such as blue-600. The same names can go straight into theme.json slugs.

If the designer cannot provide these, treat that as the first finding of the project. It is better to learn it on day one than after you have built a theme from screenshots.

Step 1: variables become tokens

Figma variables are the cleanest bridge to theme.json, because both are named values that other things point to.

The Help Center explains that variables can have modes: you “create multiple definitions for a variable, each one associated with a mode,” which lets you switch contexts such as light and dark. Variables are organized into collections. The page also says variables can reference other variable definitions, which is how a designer builds a layer of role names on top of a raw palette.

Here is a made-up Figma variable set, and how it would look in theme.json.

Figma variable (collection: Color)	Light mode	Dark mode
base	#ffffff	#0b1220
contrast	#111827	#f8fafc
primary	#2563eb	#60a5fa

The light mode values become the default palette:

{
  "settings": {
    "color": {
      "palette": [
        { "slug": "base", "name": "Base", "color": "#ffffff" },
        { "slug": "contrast", "name": "Contrast", "color": "#111827" },
        { "slug": "primary", "name": "Primary", "color": "#2563eb" }
      ]
    }
  }
}

The handbook says WordPress turns each preset into a CSS variable in the form --wp--preset--{type}--{slug}, so primary becomes --wp--preset--color--primary. It also generates classes such as .has-contrast-color for blocks that use a palette color.

What about the dark mode column?

In Figma, a mode is a second set of values for the same variable names. In a block theme, the closest match is a style variation: a second set of theme.json values that the site owner can switch to. I covered how style variations differ from patterns and template parts in Patterns, Template Parts and Style Variations. Keep the slugs identical between the two, and only the values change. That mirrors how Figma modes work.

Numbers: spacing and type

Figma number variables can hold gaps, padding and sizes. Each repeated number maps to a preset. Spacing goes under settings.spacing.spacingSizes, where each entry has a name, size and slug, and the handbook says the slug is appended to --wp--preset--spacing--{slug}. Type sizes go under settings.typography.fontSizes.

{
  "settings": {
    "spacing": {
      "spacingSizes": [
        { "slug": "20", "name": "Small", "size": "0.5rem" },
        { "slug": "40", "name": "Medium", "size": "1rem" },
        { "slug": "60", "name": "Large", "size": "2rem" }
      ]
    }
  }
}

One small trap. Figma numbers are unitless in the design, and the file may use pixels. CSS in a theme works better in rem, so that text can scale with the visitor’s browser settings. Convert on the way in, and write down the rule you used, such as “16 px equals 1 rem.”

Moving values from Figma into the file

How do the values get out of Figma? The Help Center page on variables says there is REST API and plugin API support, but it does not describe a ready-made export format, and I have not tested any export plugin. You have two safe options. Read the values in Dev Mode and type them in, which is fine for a small token set. Or ask a developer to read them through the API and write a script. For a theme with ten colors and a short scale, typing is faster and less risky.

Step 2: use Dev Mode to inspect, not to copy

Dev Mode is Figma’s developer workspace. The Dev Mode guide describes it as “a developer-focused workspace for inspecting designs, viewing properties and generated code.” You turn it on with the toggle in the toolbar, or by pressing Shift D. The page lists plan requirements: it is available on Professional, Education, Organization, Government and Enterprise plans, and a “Ready for dev” status can be set on components, frames and sections.

What you can do there:

• Read measurements. Spacing and sizing are shown, and designers can add annotations with extra context.
• See generated code. The default view in the layer properties is Code. You can choose the language and units. The page names CSS, Tailwind and React as examples.
• See variables and styles on a layer. Developers can view the variables and styles applied to a layer, which tells you whether a value is a token.
• Download assets. Icons are detected automatically and offered as downloads.

The most useful habit is to treat the code view as a hint. Generated CSS often contains absolute sizes and positions, because it describes one layer on one canvas. A theme needs the rule behind the value. If a card is 384 pixels wide in the design, ask whether it is max-width: 24rem, a column in a grid, or just the width of a sample frame.

Use the “Ready for dev” status as a gate. If a section is not marked, ask. It saves you from building something the designer is still changing.

Step 3: components become patterns, parts and block styles

This is the biggest decision in a Figma to WordPress project. Each Figma component has to become one of three things.

The Figma model is useful here. The Help Center says a main component “defines the properties of the component,” and instances “are linked to the main component and receive any updates made to the component.” That is almost exactly how a template part works. Edit it once, and every place it is used changes.

A WordPress pattern behaves like a detached copy. You insert it, and then each copy is edited on its own. Figma lets you detach an instance, which makes it a plain frame that no longer follows the main component.

So the rule is:

• A component you want linked everywhere, like the site header and footer, becomes a template part. The handbook says parts go in the parts folder, and a template includes one with <!-- wp:template-part {"slug":"header","tagName":"header"} /-->.
• A component you copy and then customize, like a hero or a pricing table, becomes a pattern. The handbook says patterns are registered by a PHP file in the patterns folder, with a header that has at least a Title, a namespaced Slug and Categories.
• A component that is a variation of a basic element, like a ghost button, becomes a block style on the existing block.
• A component with real behavior, like a calendar or a filter, may need a custom block. Leave that for last.

Variants and component properties

Figma components can have variants and properties. The Help Center page I read only links to the articles on those, so I will not describe the details. As a rule of thumb, a variant that changes the look (size, color) maps well to a block style or a pattern variation. A property that changes the content (a label, an icon) maps to a block attribute or, more simply, to text the editor types into the pattern.

A pattern from a component

Say the Figma file has a call to action component with a heading, a line of text and a button. The pattern file might look like this:

<?php
/**
 * Title: Call to action
 * Slug: mytheme/call-to-action
 * Categories: call-to-action
 */
?>
<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">
	<!-- wp:heading {"level":2} -->
	<h2 class="wp-block-heading">Ready to start?</h2>
	<!-- /wp:heading -->
	<!-- wp:paragraph -->
	<p>Tell us what you are building and we will reply within a day.</p>
	<!-- /wp:paragraph -->
	<!-- wp:buttons -->
	<div class="wp-block-buttons">
		<!-- wp:button -->
		<div class="wp-block-button"><a class="wp-block-button__link wp-element-button">Contact us</a></div>
		<!-- /wp:button -->
	</div>
	<!-- /wp:buttons -->
</div>
<!-- /wp:group -->

Notice there are no colors or sizes in it. The group, heading and button inherit them from theme.json, which came from the Figma variables. That is the payoff of doing step one first.

Step 4: auto layout becomes block layout

Figma’s auto layout and WordPress’s group block layouts solve the same problem: arrange children by direction and spacing, and adapt when content changes.

The auto layout guide describes it this way: elements are “automatically arranged in a frame based on direction, spacing, padding, alignment.” Here is how each part lines up with a WordPress block.

Auto layout property	WordPress equivalent (my mapping)
Vertical direction	Group block with the Stack layout
Horizontal direction	Group block with the Row layout
Grid	Group block with the Grid layout
Gap	Block gap setting (a spacing preset)
Padding	Padding on the group (a spacing preset)
Wrap	The wrap option on a Row layout
Hug contents	Default behavior of an unconstrained block
Fill container	A child that grows to fill the row, set in the block’s layout controls
Fixed	A set width, ideally a max width

I want to be clear that the right-hand column is my mapping, built from how the two systems describe themselves. It is not an official Figma-to-WordPress table. In particular, check the exact control names in the editor version you use, because layout controls have changed from release to release.

Two cautions from the Figma docs apply directly.

First, the docs say vertical wrap is not a masonry layout. Items keep their order and only move to the next column after the current one fills the frame’s height. If the design relies on wrap, test how it should behave with real content on a narrow screen.

Second, “Fixed” is the setting most likely to cause trouble. A fixed 1200 pixel frame is a canvas size, not a content rule. In the theme, express it as a content width in theme.json, and let everything inside flex.

Step 5: frames become templates

A Figma page usually has full-page frames: home, blog, single post, and so on. Each full-page frame that shows a type of page is a candidate for a template.

The handbook says block templates go in the theme’s templates folder, index.html is the only required file, and templates are “composed entirely of block markup.” A template typically has block markup, template part references and pattern references.

A blog post frame in Figma might have a header, a title, a featured image, the content, a related posts row and a footer. As a template, it becomes something like:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->
<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">
	<!-- wp:post-title {"level":1} /-->
	<!-- wp:post-featured-image /-->
	<!-- wp:post-content /-->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

The Post Title, Featured Image and Post Content blocks are placeholders for content that does not exist yet. The frame in Figma shows one sample post. The template has to work for every post.

Frames with sample content are pages

A Figma frame with a made-up headline and a nice photo is a page design, not a template. Do not copy the sample text into the template. Build the template, then build the real page from it, and compare it to the frame. If the real page looks wrong, go back and fix the lowest level that explains it: a token, a component or the template. This is the atomic design loop in practice.

Step 6: export images and icons

Figma can export layers, frames, components and sections. The export guide explains the steps: select the layers, add an export configuration in the Export section, and click Export. You can add several configurations to one selection, and use the Slice tool to export a specific region. There is also a bulk export with a keyboard shortcut, Shift Command E on Mac or Shift Ctrl E on Windows.

The page I read does not list formats or scale options and points to another article for them. So I will only say what a theme needs, and you should confirm the options in Figma.

• Icons and logos. Vector formats keep edges sharp at any size. Check each exported file for stray metadata and size attributes before you commit it.
• Photos and illustrations. Export at about twice the largest display size, then let WordPress create the smaller sizes.
• Content images. Do not bake them into the theme. If an image is part of a post, it belongs in the Media Library, not in a theme folder.
• Decorative images. These can live in the theme’s assets folder and be referenced from patterns.

Name the exported files after what they are, not after the layer name in Figma. Frame 2093.png will confuse the next person.

A handoff checklist

Run through this list when a design arrives, before you write any theme code.

1. Do variables exist for colors, spacing and type sizes, with role names?
2. Are the repeated pieces components, and are they in one place?
3. Do frames use auto layout, and are the settings consistent?
4. Which components are linked everywhere (template parts), and which are copied (patterns)?
5. Is there a dark mode or a second brand? If so, how is it set up in modes?
6. What is the content width, and what do the layouts do on small screens? Ask for a mobile frame if there is none.
7. Which frames are templates, and which are sample pages?
8. Are the exported assets named and sized for use?
9. What states are missing: hover, focus, error, empty, long text, right-to-left?
10. Are the frames marked ready for dev?

If you cannot tick items 1 to 3, spend an hour with the designer before you start. That hour is cheaper than a rebuild.

What will not match exactly

Be honest with the client about these before you start.

Pixel-perfect output. A Figma frame is a fixed canvas. A theme runs on every screen size. Spacing and wrapping will shift. Agree on which differences are fine.

Fonts. The design may use a font that needs a license or a different file format for the web. Check the font license and loading cost before you commit.

Effects. Some effects, such as complex blurs or layered shadows, need extra CSS or are not worth the cost. Raise it early.

Editor freedom. In Figma, nothing can break. In WordPress, an editor can add a very long title or an odd image. Test with realistic content. The accessibility side matters too, and I covered it in my WCAG 2.2 checklist for block theme authors.

Behavior. A prototype link in Figma is not working code. Hover and focus states, menus and forms are your job to build and test.

Sharing tokens beyond WordPress

If the same brand also needs a store or another front end, the token mapping above is the part you can reuse. I described a one-file approach for WordPress and Shopify in A Shopify Design System: Sharing Tokens Between Shopify and WordPress Themes. The same idea works here: Figma holds the design intent, a small token file holds the values, and each platform gets its own output.

Frequently asked questions

Can I convert Figma to WordPress automatically?

I have not tested any converter, so I cannot vouch for one. In general, a design file does not contain what a theme needs, such as which parts are reusable and which values are tokens. Expect to do the mapping by hand, even if a tool helps with part of it.

Do I need Figma Dev Mode?

Not strictly. It makes inspection faster, and it shows variables and generated code. The Help Center lists the plans that include it. If you do not have it, ask the designer for a spec sheet with the token values.

What are Figma variables?

They are named values for things like colors and numbers, and they can have modes, such as light and dark. In a WordPress project they are the best source for your theme.json palette, spacing and type sizes.

Should I build a custom block for every component?

No. Most components are patterns, template parts or block styles. Build a custom block only when the component needs behavior or settings that core blocks cannot give you.

Does a Figma component equal a WordPress block?

Not one to one. A linked Figma instance behaves like a template part, a copied one behaves like a pattern, and a variation of a basic element is a block style. Custom blocks are the exception.

How do I handle dark mode from Figma?

A Figma mode maps to a theme.json style variation with the same slugs and different values. Plan it from the start, because adding it later means touching every token.

What if the design has no variables?

Then you create the token list yourself. Collect every color, size and gap used in the file, merge near duplicates with the designer, and give each a role name. It is slow, so quote for it.

Can I use the Figma code snippets directly?

Use them as hints. They describe a layer on a canvas, so they often include fixed sizes and positions. Rewrite them as rules that fit your tokens and layouts.

The short version

Going from Figma to WordPress is a translation job. Variables become theme.json tokens, components become template parts, patterns and block styles, auto layout becomes block layout, and page frames become templates. Dev Mode helps you read the design, but the decisions about what is reusable are yours.

Start with a clean Figma file, write the tokens first, and build upward. Then test with real content, because that is where a design turns into a theme.

Source note: Figma facts and quotes come from the Figma Help Center pages on variables, Dev Mode, export, components and auto layout, read on 11 November 2026. Pages for variants, component properties and export formats were not fully covered and are not described in detail. WordPress details come from the Theme Handbook. The mapping tables and workflow are my own and were not tested with any tool, plugin or converter.