Figma to WordPress: How to Convert a Design into a Pixel-Perfect Custom Theme

Figma to WordPress is the most common handover in web projects today: a designer finishes a beautiful file, and someone has to turn it into a live, editable, fast WordPress site that looks exactly like the design on every screen. That “someone” is usually where projects go wrong – the result is a page-builder approximation, a 45 PageSpeed score and a client who keeps pointing at the Figma file and asking why the live site looks different.

I have converted hundreds of Figma, Adobe XD and Photoshop designs into custom WordPress themes for agencies and businesses, and this guide is the process I use: how to prepare the design file so the build is faster and more accurate, the decision between a custom theme and a builder, the step-by-step build from tokens to templates, how editors keep control of the content, and the quality checklist I run before handover. It is written for designers, agency owners and business owners who want to know what a good conversion looks like – and what to ask for when hiring someone to do it.

Table of contents

• What “Figma to WordPress” actually involves
• Three ways to convert a design (and which one to choose)
• Step 1 – Prepare the Figma file for development
• Step 2 – Extract the design system: tokens and components
• Step 3 – Build the custom theme
• Step 4 – Make it editable: blocks, sections and fields
• Step 5 – Responsive, pixel-perfect, on real devices
• Step 6 – Performance and accessibility from day one
• Step 7 – QA against the design and handover
• Timeline and cost
• Mistakes that make conversions look “off”
• For agencies: the white-label workflow
• Frequently asked questions

What “Figma to WordPress” actually involves

A Figma file is a static picture of the intent. A WordPress site is a system: templates that render content from the database, components that editors reuse, states (hover, focus, error, empty), responsive behaviour between the breakpoints the designer drew, and performance budgets the design never had to think about. Conversion means translating the picture into that system without losing the design’s precision – typography, spacing, colour, rhythm – while adding everything the picture does not show.

The deliverable of a good conversion is not “the home page looks like the mockup”. It is: every page type in the design exists as a template; every repeated element is a component with variants; the client can create new pages from the same components without a designer; the site scores 90+ on mobile; and the design system is documented so the next person can extend it.

Three ways to convert a design (and which one to choose)

Builders are tempting because the designer can “do it themselves”, but the 1:1 match is where they struggle: custom spacing scales, fluid type, specific hover behaviour, complex grids and performance. Most of my conversion work is the third approach (sometimes combined with native blocks): a custom theme where each design section becomes a component with the fields editors need – the way my own site is built. If you are deciding between a builder and custom code in general, I covered the trade-offs in custom WordPress development vs page builders.

Step 1 – Prepare the Figma file for development

Half of the “it does not match” problems are created before a line of code is written. A development-ready Figma file has:

• Frames for every page type and state, not just the home page: inner page, post, archive, product, 404, search results, forms with error and success states, mobile menu open, cookie banner. Missing pages get improvised by the developer.
• Consistent breakpoints: desktop (1440 or 1280), tablet (768-1024) and mobile (375-390). Designing mobile for every section is better than “the dev will figure it out”.
• Styles and variables: colour styles, text styles (a real type scale), spacing variables, effect styles. Named properly (“Heading/H2”, not “Archivo Bold 32”).
• Components with variants for buttons (primary/ghost/gold, hover, focus, disabled), cards, form fields, nav items. If a button exists in three slightly different sizes in three frames, the build will have three buttons forever.
• Auto layout everywhere – it tells the developer how the layout behaves when content changes length.
• Real content lengths: long headlines, long menu labels, 3-line testimonials, German words. Lorem ipsum hides overflow problems.
• Exportable assets: icons as SVG components, logos as SVG, photos at 2x with a note on focal points; illustrations flattened or exported.
• Interactions described: sticky header? animations on scroll? hover effects? A short notes page in the file beats a dozen Slack messages.
• Dev Mode / inspect access for the developer, with the file organised in pages (Styles, Components, Desktop, Tablet, Mobile).

When I receive a file that has these, the build is roughly 30% faster and the first review round has almost no “this is not how I drew it” comments.

Step 2 – Extract the design system: tokens and components

Before touching templates, I translate the Figma styles into a small CSS design system:

:root{
  /* colours */
  --ink:#0F1B2D; --ink-soft:#3D4A5C; --paper:#F6F7F9; --white:#fff;
  --brand:#2271B1; --brand-deep:#135E96; --accent:#E89005; --line:#E3E7EC;
  /* type scale (fluid) */
  --fs-h1:clamp(2.1rem,4.6vw,3.4rem); --fs-h2:clamp(1.7rem,3.2vw,2.4rem); --fs-body:17px;
  /* spacing + radius */
  --space-s:16px; --space-m:28px; --space-l:44px; --space-xl:88px; --radius:14px; --max:1280px;
}

Every component then uses tokens instead of raw values, so when the designer says “the blue is slightly different” it is one change, not forty. Components come next: button variants, cards, section header, form field, nav, footer columns – each built once as HTML + CSS (and a block or a section template), with the states the design shows. Fonts are self-hosted WOFF2 with only the weights in use, and the fallback stack is chosen to minimise layout shift.

This is also where I check the design against reality: contrast ratios (AA for body text), touch targets (44px), the type scale on a 360px phone, and whether the hero image as drawn can be loaded fast enough to hit a 2.5 s LCP. Problems found here are cheap; found after launch they are expensive.

Step 3 – Build the custom theme

With tokens and components ready, the theme itself is straightforward work:

1. Base: a lean theme skeleton (no parent theme bloat): header, footer, navigation with the exact menu behaviour from the design (desktop dropdowns, mobile drawer), 404, search, archives.
2. Templates per page type: home, standard page, service/feature page, blog index and single post, team, portfolio, contact – whatever the design contains. Each template is a sequence of the components above.
3. Sections as reusable units: hero, features grid, testimonials, FAQ, CTA band, logos row, pricing… each with settings (alignment, background, spacing) so the same component serves many pages.
4. Global elements from options: contact details, social links, CTA texts, footer content – editable once in a theme-options screen.
5. Per-page CSS/JS bundles: a page loads only the styles of the sections it uses, with the above-the-fold part inlined; images get correct srcset/sizes; the hero image is preloaded. This is what delivers the 90+ mobile score.
6. Integrations: the SEO plugin, forms (with a proper email service), analytics loaded after interaction, schema output for services/FAQs.

Custom does not mean “from scratch every time”. A good developer has a battle-tested starter with the performance, security and editor plumbing already solved, and spends the project time on your design. That is the difference between a two-week build and a six-week one.

Step 4 – Make it editable: blocks, sections and fields

The designer’s biggest fear about custom code is “the client will not be able to edit anything”. The opposite is true when it is done right:

• Structured sections: the editor adds a “Testimonials” section and fills in quotes, names and photos – they cannot change its typography or break the grid, but they can reorder, hide, and create new pages from the same sections.
• Native blocks for rich text: posts and text-heavy pages use the block editor; custom blocks (or patterns) provide the designed components inside it – callouts, feature lists, CTAs – with the theme’s styling applied automatically.
• Previews that match: the editor and the front end share the same CSS, so what you see is what you publish.
• Guard rails: image sizes enforced, alt text required, no arbitrary colour pickers that break the brand, one H1 per page by construction.

This editor experience is as much part of the conversion as the pixels. When I hand over a site, I record a 10-minute walkthrough video: how to edit a page, add a section, change the footer, publish a post. Support tickets drop to nearly zero.

Step 5 – Responsive, pixel-perfect, on real devices

“Pixel-perfect” means the design intent is preserved at every width, not that every pixel matches a 1440px frame on a 1366px laptop. The practical rules:

• Build from the tokens at the designed breakpoints, then test the in-between widths (1180, 1024, 900, 600, 414, 360, 320) where most real users live. My own site is checked at fourteen widths for exactly this reason.
• Fluid type and spacing (clamp()) so the design breathes between breakpoints instead of jumping.
• Real devices: an iPhone and a mid-range Android on 4G, not only browser emulation. Sticky headers, 100vh heroes and fixed bars behave differently on phones.
• Content resilience: long titles, missing images, empty states, 12-item menus, 3-line buttons in German – the layout must survive the client’s content, not just the designer’s.
• Hover on desktop, tap on mobile – no hover-only interactions that hide content from touch users.

Step 6 – Performance and accessibility from day one

A conversion that looks perfect but scores 50 on mobile has failed the client, because the design was supposed to sell. Performance and accessibility are built in, not bolted on:

• Images: WebP/AVIF exports, correct sizes, lazy loading below the fold, hero preloaded; decorative SVGs inline.
• Fonts: self-hosted, subset, two families, three or four weights.
• CSS/JS: only what the page uses, critical CSS inline, scripts deferred, no jQuery unless needed, no animation library for one fade.
• Accessibility: semantic HTML, visible focus states (designed, not browser default), keyboard-operable menus and modals, AA contrast, labels on every field, skip link. Lighthouse accessibility 100 is a reasonable target for a fresh build.
• SEO foundations: one H1, descriptive titles, schema for the relevant content types, clean URLs, fast responses.

Ask any developer you consider for a previous conversion’s PageSpeed score and Lighthouse accessibility score. Those two numbers tell you more than any portfolio screenshot.

Step 7 – QA against the design and handover

Before the client sees it:

1. Side-by-side review of every frame vs the live page at the designed width (a Figma overlay browser extension helps), then at the other breakpoints.
2. Interaction check: menus, dropdowns, mobile drawer, forms (validation, success, error, email arrives), modals, sliders, anchors, 404.
3. Cross-browser: Chrome, Safari (desktop + iOS), Firefox, Edge; Safari is where flex/grid inside buttons and sticky elements surprise people.
4. Performance + accessibility audit on three page types; fix before handover, not after.
5. Content import from the old site or the copy deck; SEO settings; redirects if URLs change (see migration without losing rankings).
6. Handover: staging review, feedback round(s), launch checklist, walkthrough video, documentation of the design system and sections.

Animations, interactions and micro-details

Designs increasingly ship with motion: reveal-on-scroll, hover lifts, counters, sticky elements, animated illustrations. The rules I follow when converting them: implement with CSS transitions and a small IntersectionObserver script rather than a 100 KB animation library; respect prefers-reduced-motion so users who disable animation get a static page; never animate layout properties that cause jank on phones (transform and opacity only); keep the first screen static so the Largest Contentful Paint is not delayed by a fade-in; and make sure every animated element has its final state as the default, so a visitor who arrives mid-page (or a search engine) sees finished content. Animated SVG illustrations – like the ones on my own service pages – are exported as self-contained SVG files with their CSS animation inside, which keeps them fast and editable in the Media Library.

Adobe XD, Sketch and Photoshop files

The process is identical for XD and Sketch; both export styles, components and assets cleanly (XD via its Share for Development link, Sketch via Inspect or a Figma import). Photoshop and Illustrator files are the exception: no auto layout, no text styles, often inconsistent spacing – expect an extra half day of “measuring and normalising” before development, and agree on a tolerance (“design intent, not pixel measurement”) with the designer. When a client has only a PDF of the design, I rebuild the key styles in Figma first; it is faster than guessing in code and it gives the client a proper source file for the future.

When the conversion is also a redesign migration

Most Figma conversions replace an existing site, which adds migration work to the build: content export from the old site (posts, pages, media, products) into the new structure, URL mapping with 301 redirects where paths change, SEO settings (titles, descriptions, schema) carried over, analytics and Search Console kept intact, and the launch sequence that avoids downtime and ranking loss. I treat the redesign as a migration project with a design component – the full checklist is in website migration without losing SEO rankings. The most common mistake is launching the beautiful new site with 40% less content than the old one “because the design only had room for three paragraphs”; rankings follow the content, so the new templates need to hold it.

Timeline and cost

For a typical business design – 8-15 page types, 15-25 distinct sections, blog, contact form, no shop – a custom conversion takes two to four weeks from a development-ready file to staging review, plus the feedback rounds. WooCommerce, integrations, multilingual and large component libraries add time. Cost depends on the number of unique sections and interactions far more than on the number of pages; a quote should be itemised that way. I quote fixed prices after seeing the file – designers and agencies get white-label rates and typically reclaim the margin they would have lost assembling it in a builder themselves. Details on the Figma to WordPress service page.

Mistakes that make conversions look “off”

• Eyeballing spacing instead of using the spacing scale – everything is 4px off and the page feels loose.
• Wrong font loading: Google Fonts link + fallback mismatch = text jumps and a slightly different weight renders.
• Ignoring line-height and letter-spacing from the text styles – headlines look “heavier” than the design.
• Stretching the container: the design is 1440 with a 1200 content width; the build uses 100% width and everything balloons on big screens.
• Builder widget defaults overriding the design (button radius, padding, shadows).
• Images exported at 1x – blurry on retina screens; or at 4x uncompressed – slow everywhere.
• Hover and focus states skipped because they were not drawn – the site feels unfinished.
• No content testing – the first real headline breaks the hero.

A 12-point design handoff checklist

Designers who want fewer review rounds can run through this before sending the file: (1) all page types framed, including blog post and 404; (2) mobile frames for every section; (3) colour, text and effect styles defined and named; (4) buttons, fields and cards as components with hover/focus/error variants; (5) auto layout on sections; (6) real content lengths tested; (7) icons and logos as SVG, photos at 2x with focal notes; (8) a notes page for interactions and animations; (9) a type scale that still reads at 360px; (10) contrast checked (AA) on text and buttons; (11) a decision on what editors may change; (12) Dev Mode access for the developer. Files that pass all twelve convert in one pass; files that pass six convert in three.

For agencies: the white-label workflow

Most of my conversion work comes from design studios and agencies who keep the client relationship and hand me the file. The workflow that works:

1. You send the Figma link (Dev Mode), a short brief (pages, integrations, special behaviour) and the deadline.
2. I reply within 24 hours with questions, a fixed quote and a timeline.
3. Build on my staging or yours; you review; one or two feedback rounds included.
4. Launch on your hosting under your name; I stay available for fixes. Your client never hears my name unless you want them to.

If you run a small studio and want a developer who treats your design as law, have a look at the portfolio or send me a file for a quote.

Frequently asked questions

Can Figma be converted to WordPress automatically?

Tools and plugins can export static HTML or builder layouts from Figma, but the results are heavy, not editable in a structured way and rarely match the design precisely. A real conversion produces templates, components and editor fields – that still needs a developer.

How long does a Figma to WordPress conversion take?

Two to four weeks for a typical business website with 8-15 page types, once the design file is development-ready; longer for e-commerce, integrations or very large component libraries.

How much does Figma to WordPress conversion cost?

It depends on the number of unique sections, page types and interactions more than the page count. Ask for an itemised fixed quote; agencies usually get white-label rates. I quote after seeing the Figma file.

Will the client be able to edit the site?

Yes. A good custom conversion gives editors structured sections and blocks with the fields they need, plus theme options for global content – visual editing without the ability to break the design.

Pixel-perfect or responsive – which matters?

Both: the design intent (type, spacing, colour, rhythm) is reproduced exactly at the designed breakpoints and behaves gracefully at every width in between, including content the designer never drew.

Should I use Elementor for a Figma design?

Only for small budgets or throwaway pages. For a business site that must match the design, load fast and stay editable for years, a custom theme (optionally with native blocks) is the better result and usually the cheaper one over time.

What do you need from the designer to start?

A Figma file with Dev Mode access, frames for all page types and the mobile versions, defined styles/components, exportable assets, and a short note on interactions and integrations.