Figma to Code: The Complete Guide

Converting a Figma design to a production website means translating a static canvas into responsive HTML, CSS, and JavaScript that loads fast, works on every screen size, and is accessible to all users. There's no magic button that does this well. Every automated tool I've tested produces code I'd be embarrassed to ship.

I've converted hundreds of Figma files into live websites. This is the workflow I actually use, not theory.

Why the Gap Between Figma and Code Exists

Figma is a design tool. It doesn't think about network requests, browser rendering, screen readers, or what happens when a headline is 4 words instead of 12. A Figma file that looks perfect at 1440px tells you nothing about how it should behave at 375px, what the hover state looks like, or how the page loads progressively.

According to a 2025 survey by Maze, 67% of developers say the biggest handoff problem is missing specifications for interactive states. The second most common issue (54%) is inconsistent spacing and component naming.

The gap isn't a technology problem. It's a communication problem. And closing it requires a specific process.

Step 1: Audit the Figma File Before Touching Code

This step saves more time than any other. I spend 1-2 hours on it before writing a single line of code.

Component consistency. Are buttons, cards, and sections built as reusable Figma components with proper variants? Or are they ungrouped layers that look the same but aren't actually connected? Inconsistency in Figma multiplies into inconsistency in code.

Responsive breakpoints. Does the design include mobile and tablet views? If it's desktop-only, that's not a design. It's half a design. You'll need to make responsive decisions yourself, and that should be scoped and priced separately.

Design tokens. Colors, fonts, spacing values. Are they consistent? I extract these into CSS variables before building anything. A site with 14 slightly different grays is a site that was designed without a system.

Interactive states. Hover, focus, active, disabled, loading, error, empty. If the Figma file only shows the "happy path," you'll discover the gaps during development when it's expensive to fix them.

Content edge cases. What happens when a name is 3 characters? What about 40? Missing images? Empty lists? These break layouts that look flawless with placeholder content.

Step 2: Pick the Right Build Platform

This is where most people overthink things. The answer depends on two questions: who needs to edit the site after launch, and how complex is the functionality?

Framer is my default for marketing sites and landing pages. Your team can update content without code. CMS built in. Great SEO output. Animations that don't kill performance. About 80% of the Figma-to-code projects I take on end up in Framer. A typical 5-page Framer build from a Figma design takes 2 weeks.

Next.js is for projects that need custom functionality. Authentication, API integrations, complex data fetching, dynamic routing beyond what Framer supports. If you need it, you need it. But don't default to custom code when Framer handles the job.

Plain HTML/CSS is rarely the right answer anymore. No CMS, no component reuse, painful to maintain. I only use it for one-off microsites with a 3-month lifespan.

Step 3: Extract Design Tokens First

Before building a single component, I pull every repeating value out of Figma and turn it into code.

Colors. Font sizes and weights. Spacing scale. Border radii. Shadows. Line heights. These go into CSS variables or a Tailwind config. It takes about 30 minutes and prevents the "why does this padding look off everywhere" problem that plagues most builds.

Most Figma files use 5-8 unique spacing values. If I find more than 12, I normalize them and check with the designer. Usually half of them are unintentional variations.

Step 4: Build Components, Then Pages

This is backwards from how most people work. They build page by page, top to bottom. I build the component library first, then assemble pages from those components.

The reason is simple: a typical marketing site has 3-5 button variants, 2-3 card styles, 1-2 nav patterns, and maybe 8-10 section layouts. Building these as isolated components first means the pages almost assemble themselves. And when the client wants to change the button radius, you change it once.

In Framer, this maps to Framer components with variants. In Next.js, it maps to React components with props.

Step 5: Responsive Is Not Optional

According to StatCounter, mobile accounts for 59.4% of global web traffic as of March 2026. If your Figma file only shows desktop, you still need to build mobile. Period.

My approach: build the desktop version first (since that's what the Figma shows), then adapt for tablet and mobile. Common responsive patterns that always come up:

Multi-column grids collapse to single column. Navigation hamburgers. Font sizes scale down (but not as much as you'd think). Horizontal sections become vertical stacks. Fixed elements need to be reconsidered on small screens.

I test on real devices, not just Chrome DevTools. The simulator lies about touch targets, scrolling behavior, and font rendering.

Step 6: Performance Is Part of the Build

A pixel-perfect site that takes 4 seconds to load is a failure. Google's research shows 53% of mobile visitors leave if a page takes longer than 3 seconds.

Images. Use WebP or AVIF. Set explicit width and height to prevent layout shift. Lazy load anything below the fold. This alone fixes most performance issues.

Fonts. Subset to only the characters you need. Use font-display: swap. Preload the primary font. Two font families is fine. Five is not.

Core Web Vitals. LCP under 2.5 seconds. CLS under 0.1. INP under 200ms. I check these on every build before handoff.

Common Mistakes I See Over and Over

Using absolute positioning for everything. Figma uses absolute positioning internally. Your code should use flexbox and grid. This is the single most common mistake I see from junior developers converting Figma files.

Ignoring the component system. If the Figma has a design system with reusable components, the code should mirror that structure. Don't build one-off divs when the design has a system.

Pixel-perfect at exactly one width. A component that looks perfect at 1440px but breaks at 1441px is not pixel-perfect. It's brittle. Build for fluidity within reasonable ranges.

Skipping accessibility. Light gray text on white backgrounds. 24px click targets. No alt text. No keyboard navigation. WCAG AA compliance is the baseline, not a nice-to-have. About 15-20% of users have some form of disability that affects how they use the web.

When Automated Tools Work (and When They Don't)

Tools like Locofy, Anima, and Builder.io have gotten better. They're useful for pulling spacing values and generating a rough starting point. But I've never shipped code from an automated Figma-to-code tool without rewriting 60-80% of it.

They work for: quick prototypes, design exploration, extracting design tokens.

They don't work for: production websites, responsive layouts, accessible markup, anything with complex interactions.

My Workflow (What I Actually Do on Every Project)

1. Audit the Figma file (1-2 hours). Note inconsistencies, missing states, responsive gaps.
2. Extract tokens (30 min). Colors, fonts, spacing into code variables.
3. Build components (2-3 days). Button, card, nav, section components with all variants.
4. Assemble pages (2-3 days). Compose pages from components, add real content.
5. Responsive pass (1 day). Test and fix across breakpoints and real devices.
6. Performance audit (half day). Lighthouse, WebPageTest, image optimization.
7. Client review (1 day). Side-by-side with Figma, fix discrepancies.
8. Launch (half day). DNS, analytics, meta tags, final checks.

Total: about 2 weeks for a 3-5 page site. Larger sites scale linearly.

If you have a Figma design that needs to become a real website, I can help. I specialize in Figma-to-Framer conversion with UX copy review built into the process. Check my services or book a call.