A Figma file is a picture of a website at three or four specific widths. A WordPress site has to work at every width, with content nobody has written yet, edited by someone who has never opened Figma. Converting one into the other is mostly the work of deciding what happens in the gaps between the artboards.
That is why the one-click export plugins disappoint, and why a good conversion asks you questions your design did not answer.
The three routes, and what each really produces
- Automated export. A plugin reads the Figma file and emits markup. It reproduces the desktop artboard closely and produces absolutely positioned output with a class name per layer, no semantic structure, and nothing that survives a content change. It is a demo, not a site. The honest use for it is showing a client a static page quickly.
- Rebuild in a page builder. Someone recreates the design in Elementor, Bricks or similar. Fast, editable by a non-technical person, and the layout ends up owned by the builder — the markup is heavier than the page needs, and moving off it later means rebuilding again. Reasonable when the client already uses that builder and intends to keep it.
- Build a block theme. The design’s spacing, type scale and palette become
theme.jsonpresets, and the layouts become block templates and patterns built from native WordPress blocks. Slower to start, and it produces a site that loads the markup the page actually needs, is edited in the standard editor, and has no dependency on any third-party layout tool. This is what we build.
None of these is universally right. The third costs more at the start and less over the life of the site, which is the same trade as everywhere else in this business.
Why exported code does not survive
Because the export has no idea what anything is. It knows a rectangle sits at those coordinates in that colour. It does not know that the rectangle is a card, that there will eventually be nine of them, that they come from a database, or that the heading inside is an h2 rather than 24px bold text.
Everything that follows from that is predictable. The page breaks the moment a heading runs to two lines, because the design assumed one. Nothing is a reusable block, so a new page means starting over. Nothing is editable in WordPress, because there is no block structure to edit — only markup. Screen readers get a page of anonymous divs. And Google gets no heading hierarchy at all, on a site whose whole purpose is to be found.
The conversion work is the part the export skips: deciding what each element means, which parts repeat, which parts are content and which are structure.
What makes a Figma file convertible
Files vary enormously, and the difference lands directly on the price and the timeline. A file with these things in it converts quickly and predictably.
- Auto layout on anything that repeats. This is the big one. Auto layout states how things space and how they respond to a longer label. Without it we are measuring gaps between rectangles and guessing which measurements were intentional.
- Colour and text styles, not local overrides. Defined styles map straight onto
theme.jsonpresets and become the site’s palette and type scale. Nineteen hand-picked near-identical greys become nineteen decisions somebody has to make. - Components for repeated elements. One button component with its states beats forty button instances that disagree about padding.
- At least two widths per template. Desktop and mobile. Without the mobile artboard, someone is inventing your mobile design, and it will be us.
- The awkward states drawn. Empty states, error states, a long product name, a card with no image, the menu open. These are where builds stall, because they are the questions the design did not answer.
- Fonts named, with licences you hold. A font that cannot be licensed for the web has to be substituted, and that changes the design.
A file missing most of this can still be built. It just moves the design decisions into the build, which is slower and produces a site the designer did not fully specify.
The gap between three artboards and every screen
Designs are usually drawn at 1440, sometimes 768, usually 390. Real visitors arrive at every width in between, plus a few outside. Most of the disagreement in a conversion project happens in that space.
A four-column row is drawn at 1440 and drawn stacked at 390. Between them it can go to two columns, or three, or scroll sideways, and the file does not say which. A heading set at 56px is right at 1440 and enormous at 900, so it has to scale — smoothly, or in steps, and again the file does not say. A hero image cropped beautifully at desktop has its subject cut out of frame on a phone unless a focal point is agreed.
None of this is a fault in the design. It is simply not what a static design tool records. A conversion that does not raise these questions is not avoiding them — it is answering them without telling you.
Design decisions that get expensive in WordPress
A few things are cheap to draw and costly to build, and they are worth knowing about while the design can still change.
- Text set over a photograph with no plate behind it. Fine with the chosen image, illegible with the one the client uploads next year. Design a scrim or a solid area so the layout still works with any photograph.
- Twelve near-identical section layouts. Each one is built and tested separately. Consolidating them into four with variations costs nothing visually and a great deal in build time.
- Cards that only work at one text length. Real titles run long. If the design does not tolerate two lines, every editor becomes a copywriter constrained by pixels.
- Heavy scroll animation. Cheap in a prototype, and the thing that lands on Cumulative Layout Shift and Interaction to Next Paint in the finished site. Worth deciding deliberately rather than inheriting — see does site speed affect Google rankings.
- Amber, or any light colour, used as body text. It looks right on a designer’s calibrated screen and fails contrast requirements in practice. Light brand colours belong in fills, with a darker relative for text.
What a finished conversion should include
“Matches the design” is only the first check, and it is the easiest one to pass. The rest of it:
- Every layout editable in the WordPress editor by someone who has never seen the design file
- Repeating sections available as patterns, so new pages are assembled rather than rebuilt
- The palette and type scale in
theme.json, so a brand change is one file and not a search across stylesheets - Correct heading order, real landmarks, keyboard-reachable navigation and visible focus states
- Images sized and served responsively, not one desktop asset scaled down on phones
- Checked at real widths between the artboards, not only at the three that were drawn
Figma to WordPress starts at $450. What moves it from the floor is the number of distinct layouts and how much of the responsive behaviour the file leaves open — which is why the audit looks at the actual file before quoting rather than pricing per page.
What this cannot fix
- We do not redesign the design. We build what is in the file. If something in it will not work — contrast, a layout that cannot survive real content — we say so before starting, but the design decisions stay with your designer.
- A pixel-identical match at every width is not a thing that exists. The design specifies three widths; the browser has infinite ones. We match the artboards and agree the behaviour between them. Anyone promising pixel-perfect everywhere has not thought about it.
- A conversion does not fix a design that does not convert. If the page does not make its case, building it faithfully in WordPress produces a faithful version of that.
- Sketch, XD and PDF are a different job. We work from Figma. A flattened PDF or a JPEG of a design is not a specification, and quoting from one would be quoting from a guess.
Questions we get asked
Can I convert Figma to WordPress automatically?
You can generate markup automatically, and it will look like the desktop artboard. What it will not be is a WordPress site: no block structure, so nothing is editable in the editor; no semantic headings, so search engines and screen readers get nothing; absolute positioning, so it breaks when a heading runs to two lines. Useful for showing a client a static page quickly. Not something to launch.
How much does Figma to WordPress cost?
Ours starts at $450. The variables are the number of genuinely distinct layouts — not pages, since repeated layouts are nearly free — and how complete the file is. Auto layout, defined colour and text styles, components and a mobile artboard all reduce the price, because each one removes a decision somebody would otherwise have to make during the build. The audit reads the actual file and returns one fixed number.
Should the site use a page builder or a block theme?
A block theme if you want the lightest markup, no third-party dependency and standard WordPress editing. A page builder if your team already uses one and intends to keep it, since retraining has a cost too. The thing worth knowing before choosing is that page builders are hard to leave — the layout lives in the builder’s own format, so moving off it later means rebuilding rather than switching.
What do you need from me to start?
View access to the Figma file, desktop and mobile artboards for each template, the font files or licences, and a note of anything dynamic — which sections pull from posts or products rather than being typed in. If the awkward states are drawn as well, empty states and long titles and the open menu, the build gets meaningfully faster.
Will the finished site be editable without a developer?
That is the point of building it as a block theme. Layouts are native blocks, so text, images and links are edited in the standard WordPress editor. Repeating sections are saved as patterns, so a new page is assembled from pieces rather than rebuilt. Colours and type live in theme.json, which is the one part that stays a developer job — and it is one file rather than a hunt through stylesheets.
Can you quote from my Figma file?
Yes. Send a view link through the contact form. Within two business days you get a written reply: how many distinct layouts we count, which parts of the file will speed the build up, which questions the design has not answered yet, and one fixed price in USD. If the file is not ready to build from, the audit says what is missing rather than quoting around it.