Figma has no built-in HTML export. Dev Mode and Copy as code give you CSS for one layer at a time. The HTML comes from somewhere else: a converter plugin, the Figma MCP server with a coding agent, or an AI tool that imports Figma frames.
All of them follow the same rule. A converter turns what the frame contains into HTML and CSS well: layout, spacing, color, type, text and images. It misses what the frame does not contain: which box is a button, the hover and focus states, the widths nobody drew, your code's token names and the alt text.
That makes the hand-fix list predictable, so you can plan for it before you convert. It also means no converter makes the code production-ready. Where the code lands does that. How a Figma file compares with screenshots, prompts and designing in code is in all the routes from a design to code.
Key takeaways
- Dev Mode's built-in code languages are CSS, SwiftUI or UIKit, and Compose or XML. HTML and React come from codegen plugins or the MCP server.
- The Figma MCP server writes React and Tailwind by default and plain HTML and CSS when you ask. Figma says it is not designed to return production-ready code.
- The hand-fix list covers semantics, states, responsive widths, tokens and accessibility. The WebAIM Million lists missing alt text and form labels among the most common failures on home pages.
Ways to convert Figma to HTML and CSS
Eight ways get you from a Figma frame to web code.
| Way | What you get | Good for | What it misses |
|---|---|---|---|
| Dev Mode or Copy as code | CSS for one layer | Exact values | The HTML and the page structure |
| Converter plugin: Anima, Builder.io Visual Copilot, FigmaToCode | HTML and CSS, or React, Vue and Tailwind | A static page or a first draft | Semantics, states, your components unless mapped |
| Figma MCP server and a coding agent | Design context, written as React and Tailwind by default | Code in your own repo | Production-ready code, by Figma's own description |
| AI tool with Figma import: v0, Bolt, Kombai | An app or components built from the frame | Prototypes, or a repo the tool can read | Your conventions, unless it reads your repo |
| Paste beside your running app: Modeinspect | The frame built into your app's code by a coding agent, as a pull request | Screens in Next.js React codebases that use Tailwind | Linked components and tokens, since instances arrive as plain layers and variables do not become tokens |
| Figma Make | A React app, as a .zip or a one-way push to its own GitHub repo | Interactive prototypes | Plain HTML, and the repo you already have |
| Figma Sites | A site published from Figma | Pages that can stay on Figma | The code, which cannot be exported |
| Rebuild by hand | Code a front-end engineer writes | Pages that must fit a codebase | Nothing, but it takes the longest |
Figma Dev Mode code settings: language options for HTML, CSS and React
Dev Mode's built-in code languages are CSS for the web, SwiftUI or UIKit for iOS, and Compose or XML for Android. There is no HTML or React option. To switch languages, select a layer, set the properties panel to Code and pick one from the dropdown.
HTML and React come from codegen plugins, which add their languages to that same dropdown, or from the MCP server. A React conversion adds its own fix: generated components that ignore the props your existing ones already have. On Organization and Enterprise plans, Code Connect shows developers your design system's code in place of the generated snippet.
The CSS is good for the exact values of one layer: size, padding, gap, color, type and radius. Auto layout comes out as flexbox, and the updated auto layout, the default for new frames since July 2026, maps to it more directly. The panel describes one layer, not a page: no document structure, no semantic elements, and widths in the fixed units you drew.
Dev Mode needs a Full or Dev seat on a paid plan, and Copy as code works on any plan. Whether your developers need a paid Dev seat for the handoff depends on how your team hands off designs.
How to convert Figma to HTML, step by step
Five steps: prepare the frame, decide where the code goes, convert section by section, fix by hand, and check it in a browser. Most of the quality is decided in the first two.
- Prepare the frame. Use auto layout on every frame. Figma's advice for preparing a file for its MCP server holds for any converter: apply variables for spacing, color, radius and type. Name your layers, or
Frame1268becomes a class name. Draw one frame per breakpoint and name the frames as a set. - Decide where the code is going. Plain HTML and CSS suits a static page. If the screen goes into an app, convert to what the app uses: React components, Tailwind classes from your theme or a Next.js page. HTML rewritten into components later is two conversions, not one.
- Convert one section at a time. Select a header, a card grid or a footer, not the whole page, so you can check the code line by line. With the MCP server, select the section in Figma or paste its link, then use Figma's example prompt, "generate my Figma selection in plain HTML + CSS".
- Run the hand-fix pass. Work through the table below before anyone else sees the code.
- Check it in a browser. Resize the window slowly between your breakpoints. Tab through the page and check that every link and button shows focus. Then ask a front-end engineer to review it like any other code.
What converters get right and what you fix by hand
Padding, gaps, colors, font sizes, line heights and radii come across as the numbers in the file, copy arrives as written, and auto layout comes out as flexbox. FigmaToCode can embed vector shapes as SVG. For a static page, most of the visual work is done once the converter runs.
You fix what the frame does not contain: what each element is, how it behaves, the widths nobody drew, your token names, alt text and font loading.
| What to fix | Why the converter misses it | The fix |
|---|---|---|
| Semantic elements | The frame is nested boxes, so out come <div>s. PaperStreet, testing Locofy, found "div soup" and several <h1> tags on one page (PaperStreet) | Landmarks such as header, nav and main (W3C), one h1 |
| Buttons and links | A rectangle with text looks the same whether it submits a form or opens a page | <button> and <a>, which have keyboard access built in (MDN), each with an accessible name |
| Form labels | A text layer above a box is not tied to the input | A <label> for each field (W3C) |
| Hover, focus and disabled states | A frame shows one state. The others live in other frames, if anyone drew them | Each state in CSS, with focus always visible (W3C, MDN) |
| Responsive widths | The frame has one width. A FigmaToCode issue reports that the default mode "often generates layouts using position: absolute" (GitHub) | Flexible widths, rem units (MDN), media queries between your frames |
| Tokens | Variables keep Figma's names, and anything without a variable arrives as a raw hex code or pixel size | CSS custom properties for repeated values (MDN), named after your design tokens |
| Fonts | The frame names a font, not its files | Font files loaded, with fallbacks |
| Images | The frame has pixels, not a description or a size per screen | Alt text, empty alt for decorative images (W3C), responsive images (MDN) |
A typical fix: the converter sees a rounded rectangle with a label, and you know it is a button.
<div class="frame-1268">Send message</div>
<button type="submit">Send message</button>
The WebAIM Million lists the most common accessibility failures on home pages: low-contrast text, missing alt text, missing form labels, empty links and empty buttons (WebAIM). The table covers four of the five. Contrast starts in the design file.
If you are the one designer next to a dozen engineers on a Next.js and Tailwind codebase, you have probably run this loop already. You converted a frame with Anima or copied the CSS out of Dev Mode and opened a pull request. The review came back as a list of hardcoded values and a component the codebase already had. Leadership still wants AI to shorten the handoff. The converter did its job. The code did not land.
We hear the same thing on our calls with customers: the generated code ignores the design system, recreates components the team already has, and hardcodes values instead of using tokens. The HTML and CSS does not survive an engineer's review. Erez Cohen compared Locofy, Anima and v0 on dev.to and concluded that, for enterprise-grade projects, these tools "aren't quite there yet".
Which AI tool gives production-ready HTML and React exports?
Production-ready is a property of where the code lands, not of the export. No tool turns a Figma frame into production-ready HTML or React on its own. An export is production-ready when it fits the codebase it lands in: your components and tokens, your conventions, and a passed code review. A clean React file with its own Button is still a second Button that someone has to merge away.
Puck's roundup of UI generators ties the phrase to the design system: "every generated UI is production-ready and stays consistent with your design system". The same test sorts the AI tools into two groups.
- Tools that read your repo. Claude Code or Cursor with the Figma MCP server, Kombai, Builder Code (formerly Fusion), and v0 or Bolt with an imported repo (v0, Bolt). Point Kombai at a frame and a repo and it builds the frame from "components, tokens, and hooks from your repo, npm package, or Storybook".
- Tools that export a new artifact. Anima's plugin, FigmaToCode, Figma Make's .zip and Visily. Anima says your own components need its separate VS Code tool. Visily calls its export "a development starting point".
The first group can close the Tokens row and reuse your components instead of recreating them. Semantics, states and alt text still need a person.
The MCP server itself is in neither group. What it sends is context, not finished code: Figma says the server "isn't designed to return production-ready code". The coding agent writes the files in your repo. Setup and seats are in how the Figma MCP server works and where it stops. How the workflow around these tools changes is in rethinking the Figma to code workflow.
Modeinspect takes the test literally: the frame is built where it will ship. You paste a Figma frame, or a link to one, onto a canvas that holds the live pages of your app. You drop it onto the page where it belongs, and the coding agent builds it into that page's code, following your design guidelines and Tailwind theme. The change leaves as a pull request for engineers to review.
It works on Next.js React codebases that use Tailwind. Component instances arrive as plain layers and Figma variables do not become tokens, so an engineer still checks components and the Tokens row in review. For a wider comparison, see AI tools for designers, sorted by where the output lands.
So pick the converter by where the code lives. Before you convert, write down what the frame cannot carry: which element is which, the states, the widths between breakpoints and the alt text. For a static marketing page, run a plugin and the hand-fix pass. For a screen in your app, use a tool that reads the repo. Paste the same list into the pull request, so the engineer reviews the page instead of rewriting it.
Frequently asked questions
Can Figma export HTML?
Not on its own. Dev Mode and Copy as code give you CSS, SwiftUI or UIKit, and Compose or XML, with no built-in HTML option. Figma Sites generates HTML when it publishes, but you cannot export that code. For HTML files, use a codegen plugin or the Figma MCP server.
Is there a free Figma to HTML plugin?
Yes. FigmaToCode is open source under GPL-3.0 and generates HTML, React, Svelte, Tailwind, Flutter and SwiftUI from a selection. Builder.io's Free plan includes its Figma plugin. Free or paid, the output needs the same hand-fix pass.
Can AI convert Figma to HTML?
Yes, with the Figma MCP server and a coding agent such as Claude Code or Cursor. Its default output is React and Tailwind, so ask it to "generate my Figma selection in plain HTML + CSS". AI tools such as v0 and Bolt also import Figma frames. Either way, the frame is all the AI knows about the design, so semantics, states and alt text still need a person.
Is converted Figma HTML production-ready?
Not as it comes out of the converter. Converted HTML becomes production-ready once it uses your components and tokens, follows your conventions and passes code review. Tools that read your repo get closer, because they can reuse what the codebase already has.
Should I convert Figma to HTML or to React?
Convert to what the page will live in. Plain HTML and CSS suits a static page, a landing page or a prototype nobody will merge. A screen in a React app should come out as React built from the app's own components, or the HTML gets converted a second time.
Is the HTML from a Figma converter responsive?
Not from one frame. A frame has one width, so the converter has no other widths to write, and some, like FigmaToCode's default mode, fall back to absolute positioning. Use auto layout, draw one frame per breakpoint, and write the media queries between them by hand.
Can Figma Make export HTML?
Not plain HTML. Figma Make builds a React app, which you can download as a .zip or push one way to its own GitHub repo. To get plain HTML out of it, you convert the React app yourself.
Can you convert HTML back into Figma?
Yes, with a plugin. html.to.design imports a web page into Figma as editable layers. It helps when the live site has moved on from the file and the file needs to catch up.