HTML to Figma

The import plugins — the html.to.design family and similar browser extensions — do something genuinely clever. They read the rendered DOM and computed styles from a URL and rebuild it as Figma layers, so within about a minute you have your homepage on a canvas with roughly the right colours and positions. For grabbing a competitor layout as reference, that is exactly the right tool and we use them for that.

The trouble starts when you try to work with it. What arrives is a snapshot of one page at one viewport: a deep tree of absolutely positioned frames named after CSS classes, no components, no auto-layout, no text or colour styles, and no variables. Change the padding on one card and the other five do not move. Nothing is reusable, so every edit is manual, and the file becomes harder to work in than starting from an empty canvas.

It is also lossy in ways that are easy to miss until they bite. Hover, focus and active states never appear, because the DOM was captured in one state. Anything behind an interaction — dropdowns, modals, accordion panels, tabs beyond the first — is simply absent. Web fonts sometimes map to a substitute. And you get exactly the breakpoint the capture ran at, so a responsive site imports as whichever single width the browser happened to be.

What we do instead is rebuild rather than import. We read your live site properly — the real spacing scale, the actual type ramp, every colour in use, and the full component inventory including the states that only exist in CSS — and construct a Figma file the way a designer would have built it in the first place. Components with variants, auto-layout that resizes correctly, and the design tokens declared as Figma variables.

The audit is often the more valuable half. Rebuilding a site as components forces every inconsistency into the open, and there always are some: the eleven greys that were meant to be three, the four button heights, the six near-identical cards, the type sizes that drifted over years of edits. You get that inventory as a document alongside the file, which is usually the first thing a redesign actually needs.

And because we build front ends as well, the file is made to be buildable. Components map onto things that can exist in code, tokens are named the way they will be named in CSS, and the structure anticipates the build — so when the redesign goes the other way through Figma to HTML or Figma to React, the round trip is clean.

Send the URL. We will tell you how many distinct components the site really contains — which is almost always fewer than the page count suggests, and the number your redesign budget should be based on.