Figma to WordPress: how a pixel-faithful conversion actually works

You have a Figma file signed off by the client, and now it has to become a real WordPress site. The design is precise - exact spacing, a proper type scale, states drawn out. The worry is the handoff: you have seen “conversions” come back approximate before, close from a distance and wrong the moment you look at a real page on a real phone.

That gap costs you the part that matters. A client approves a design, then sees a build that is a few pixels loose everywhere, breaks between the widths the designer drew, and has no idea what a hover or an error state should do. Now you are in revision cycles defending work you outsourced, under your brand, against a design your client is holding up next to it.

The difference between faithful and approximate is not talent or effort. It is process - a specific, boring, checkable process. Here is what it is, so you can tell which one you are buying before the client does.

We build these for agencies, so the bias is stated: we are a white label WordPress agency, and pixel-faithful builds from supplied designs are a large part of what we ship. When a global music brand needed a campaign site built to exact brand guidelines and live on a fixed date, that is the work - the Warner Music build shipped pixel-faithful, on the date, fast on mobile.

What a faithful conversion actually is

A faithful Figma to WordPress conversion is a hand-built theme driven by the design’s own tokens and verified against the file at every breakpoint. It is not a screenshot of the design turned into HTML. Four stages make it faithful rather than close:

1. Extract the tokens. Pull the design’s colors, type scale, spacing and radii out of Figma as named values - the design system’s source of truth - instead of eyeballing hex codes off the canvas.
2. Load them into the theme. Put those tokens into WordPress so the whole site inherits the exact design decisions. Modern block themes do this through theme.json global settings and styles, which turns the palette, type scale and spacing into the site’s baseline rather than per-page guesswork.
3. Build components from the bottom up. Map each unique element - buttons, then cards, then headers and full templates - to a real WordPress equivalent, built once and reused, so the button on page 12 is the same button as on page 1.
4. QA against the file. Compare the rendered site to the Figma design directly, measuring the things browsers and Figma render differently: line height, letter spacing, shadow spread, border radius.

An automated exporter skips straight from “the canvas” to “some HTML” and calls it done. That is where approximate comes from.

Why automated exporters produce approximate sites

Figma-to-WordPress exporter plugins and AI converters are real, and they are genuinely fast. They are also the wrong tool for a client site, for reasons that are structural, not fixable with a better plugin.

They read the canvas literally. A designer positions elements on an artboard; the exporter reproduces that positioning with absolute coordinates and fixed widths. It looks right at exactly the width the designer drew and comes apart at every other width, because absolute positioning is not how a responsive site works. The markup underneath is deep, bloated and locked to that one layout - the same problem we wrote about in why page-builder bloat hurts, arrived at from a different direction.

Then there is everything the exporter cannot see. A static file has no hover state, no focus ring, no loading spinner, no empty cart, no error message, no idea what happens when the heading is three lines instead of one. The exporter ships the one frozen state it was given. A developer has to build the rest - which means the “conversion” was the easy 60%, and the 40% that decides whether the site actually works was never touched.

For a microsite live for six weeks, that trade can be fine. For a site your client has to run and update for years, it is a maintenance liability handed over as a finished product.

The breakpoint gap: where “it doesn’t match the design” comes from

Here is the single most common reason a build and a design diverge, and almost nobody names it.

A Figma file is a set of fixed frames. The designer draws desktop at 1440 and mobile at 390, maybe a tablet frame in between. Those frames are exact. What the file does not contain is what the layout does at 900, at 1200, at 375 - the widths between the frames, where most real screens actually sit.

Those in-between decisions have to be made by someone. A faithful build makes them deliberately, with the designer’s intent in mind: how the grid reflows, when three columns become two then one, how type scales down, what the header collapses into. An approximate build either freezes at the drawn widths and breaks between them, or lets the browser guess and calls the result close enough. When a client says “it doesn’t match the design,” nine times out of ten they are looking at a browser width the designer never drew and the developer never decided.

A good conversion process treats the breakpoints between frames as part of the brief, not an afterthought. That is a conversation with whoever owns the design, and it is why a genuinely tokenized, well-annotated Figma file converts faster and truer than a beautiful but literal one.

What is not in the file - and has to be faithful anyway

Faithful cannot only mean faithful to the static frames. The site has to be faithful once real content and real interaction exist, and that is a larger surface than the file shows:

• Interaction states - hover, focus, active, disabled. Accessibility depends on the focus ring in particular, and the WordPress coding standards target WCAG AA for exactly this reason. If the design did not draw these, they get designed into the build, not skipped.
• System states - loading, empty, error, success. A form has to say something when it fails; a listing has to look right with zero items and with a hundred.
• Real content - the heading that runs long, the product name in German, the missing image. Designs use tidy placeholder content; the build has to hold up when the real thing is messy.
• Multiple languages - a site in several locales has to stay faithful in all of them. On the Tectyl Europe build that meant product data across 18 European locales staying correct and on-brand in every one; a layout that only works in English is not faithful, it is unfinished.

None of this is in the Figma file. All of it decides whether the shipped site earns the word faithful. This is where a build team that has run real sites in production pulls ahead of anything that reads a canvas and stops.

How to tell a faithful partner from an approximate one

Before you hand over a design, ask four questions. The answers sort the two apart fast:

• “How do you handle the widths between my Figma frames?” A faithful partner talks about breakpoint behavior as a decision to make with you. An approximate one says the site is responsive and moves on.
• “What do you do about states that aren’t in the file?” You want to hear hover, focus, loading, error, empty, and real content named back to you.
• “Do I get a maintainable theme or exported markup?” Clean, tokenized, standards-based code you can hand to any developer, versus a locked export, is the whole difference in year two.
• “How do you QA against the design?” A real answer describes measuring the rendered site against the file, not “we eyeball it.”

A partner who has only ever run designs through an exporter cannot answer these without hedging. A partner who builds by hand answers them in specifics, because they are the specifics of the job.

When approximate is actually fine

The honest boundary: not every design needs a pixel-faithful hand build.

If it is a throwaway campaign page with a fixed lifespan, an exporter or a fast approximate build can be the right economic call - you do not pay for a decade of maintainability you will never use. If the design is a rough direction rather than a signed-off spec, faithful is premature; the design is still moving. And if nobody will ever update the site, the maintainability argument loses most of its force.

The faithful build earns its cost when the design is final, the site has to live and be updated, and it carries a brand someone will hold the result up against. That is most client work, which is why it is the standard worth defaulting to.

We convert Figma to WordPress by hand for agencies across Europe and North America - tokenized, tested against the file, in code that is yours - under your brand, NDA by default. If you have a design that has to ship faithful, start here, and see the builds the process produces.