Two phrases sit one small preposition apart, and point in opposite directions. Figma to HTML. HTML to Figma. People reach for the wrong one constantly — and then spend the next hour fighting a tool that was never built for the job in front of them. The fix is almost embarrassingly simple: work out which way you're actually travelling before you start.
Figma to HTML turns a design into code: design → build. HTML to Figma turns a live page into editable design: web → Figma. Opposite directions, opposite jobs — and which you need comes down to what you have in hand.
Two directions, two jobs
The confusion is understandable. Both phrases involve Figma, both involve HTML, and both promise to carry your work across the gap between design and code. But the arrow matters more than the words around it.
Figma to HTML starts with a finished design and produces code — markup and styles an engineer can build from. You're leaving the design tool, heading toward the browser. HTML to Figma runs the other way: it starts with something that already lives on the web — a page, a file, a snippet — and brings it back into Figma as layers you can edit. You're leaving the browser, heading toward the canvas.
So the deciding question isn't which tool is better. It's which way you need to go. Put the two side by side and the choice makes itself.
Side by side
Here's the same comparison laid out plainly — what you start with, what you walk away with, and where each direction tends to bite.
| Figma → HTML | HTML → Figma | |
|---|---|---|
| Starting point | A finished Figma design | A live page, an HTML/CSS file, or pasted markup |
| You get | Code or markup you can build from | Native, editable Figma layers |
| Best for | Handing design to engineering; turning a mockup into a working prototype | Redesigns, audits, teardowns, and reusing a site that already shipped |
| Watch for | Generated code is a starting point, rarely production-final | Non-installed fonts, CORS-locked assets, canvas/WebGL content |
Figma to HTML: a design becomes code
This direction takes the layout you've already drawn — frames, text, components — and writes it out as HTML and CSS. The point is to get a head start on building: instead of an engineer reading the design and typing every rule by hand, the tool proposes a first pass they can refine.
It's genuinely useful, and plenty of people reach for it. Engineers picking up a handoff want structure to build on, not a blank file. Designers prototyping an idea want a clickable, real-browser version of a static mockup. For both, generated code shortens the distance from picture to working page.
The honest caveat: what comes out is a starting point, not a finished build. Generated markup tends to lean on absolute positioning and auto-named classes; it rarely arrives with the semantic structure, accessible markup, or responsive behaviour a shipped product needs. Expect to refine the structure, tidy the semantics, and rework how it reflows across screen sizes. Treated as a draft, it saves real time. Treated as production-final, it disappoints — so treat it as a draft.
HTML to Figma: a live page becomes editable design
Run the arrow the other way and you get the job this site is built around. Instead of exporting a design out, you bring a page in: an existing website, an .html file, or markup you paste — rebuilt inside Figma as native layers. Live text you can retype, fills you can recolour, frames you can restyle.
Who reaches for it? Designers redesigning a site that already shipped, who'd rather start from the real thing than trace a screenshot. Teams auditing a live page for spacing, type, or colour drift. Anyone who needs to reclaim a product that has no Figma file behind it — the design was lost, or never existed, and the running site is the only source of truth.
This is the direction Vellum works in. It rebuilds the page as editable layers measured from the real browser render — every position, size, and font weight read from what the browser actually drew, rather than guessed at — so the import lands where the page really sits. For the full walkthrough of getting a page onto the canvas in the first place, see importing a website into Figma.
How to choose, in one question
Skip the feature lists and ask yourself one thing: do you have a design and want code — or a page and want design?
If you have a finished Figma file and you're trying to get it into the browser, you want Figma to HTML. You're moving toward build. If you have a live page — or a file, or a snippet — and you want to edit it as a design, you want HTML to Figma. You're moving toward the canvas. That single question settles almost every case.
The one that trips people up is the redesign: it feels like a design task, so the instinct is to open a blank Figma file and rebuild the old page from memory. But you already have the page — so the faster route is to pull it in and edit from there. That's HTML to Figma, and it's exactly how you'd redesign a site without rebuilding it from scratch.
Know your direction
Neither direction is the winner; they're answers to different questions. Figma to HTML carries a design toward the browser. HTML to Figma carries a page back to the canvas. Work out which way you're going before you pick a tool, and the hour you'd have lost fighting the wrong one stays yours. Have a design, want code? Go one way. Have a page, want design? Come the other.