2026년 7월 8일 • ☕️ 5 min read
At a redesign kickoff, our designer asked: “Can I get the current screens in Figma?” Not screenshots — something she could actually edit.
The old answer was someone tracing rectangles over a screenshot for half a day. The current answer is a category of tools that read a page’s DOM and computed styles and rebuild it as real Figma nodes. Since some of the screens I needed to migrate sat behind a login, I ran three of these tools against real pages to see what survives and what breaks.
One confession before we start: one of the three, html2figma, is a tool I built. I’ve deliberately spent more words on its limitations than its strengths here. Discount accordingly.
I ran three kinds of pages through each tool. If you write frontend code for a living, you can already guess where each one gets interesting:
::beforelocalhost:3000 — not deployed anywhereFour things I checked: does text arrive as real text nodes (not flattened images), do SVGs convert to vectors, does the tool build a sane Auto Layout structure, and is the layer tree something a human can navigate.
The best-known tool in this space, and after using it you understand why.
The workflow is the star. You type a URL inside the Figma plugin and their server renders the page and drops the result into your file — you never open a browser tab. Importing desktop, tablet, and mobile viewports in a single pass is genuinely the best starting point for a responsive redesign I’ve seen. Conversion quality on the landing page was solid: text, gradients, and SVGs all came through cleanly.
Pages 2 and 3 are where things get complicated. Server-side rendering obviously can’t see behind your login session or reach localhost. There’s a Chrome extension path for that, but it still means your admin panel’s DOM transits a third-party server — if your org has a security review process, expect questions. I wouldn’t point it at an internal dashboard.
Pricing: $12/month billed annually ($144/year) or $18/month billed monthly, per user. Free tier is 10 imports per 30 days. For an agency batch-importing a fifty-page site, the price is easily justified. For individual use it’s on the steep side.
This is mine. I built it precisely because of where the previous tool’s approach stops, so the architecture is different.
The Chrome extension reads the page as it currently exists in your tab via the Chrome DevTools Protocol’s DOMSnapshot. Because it captures actual browser state rather than a server re-render, login sessions, localhost, and even A/B variants only you can see all capture exactly as rendered. The capture leaves your machine only as a .h2f file (JSON) or through your clipboard — nothing is stored server-side. Migrating the admin dashboard is exactly the case this was built for.
Fidelity is where most of the engineering time went: icons drawn with ::before/::after, asymmetric borders, merged iframe and shadow DOM capture, and inline SVGs converted to editable vectors. Large pages stream over in chunks. On the Figma side, the plugin generates Auto Layout and Local Styles (color/text), which meaningfully cuts the cleanup work afterward.
Now the honest downsides. First, Chrome shows a “this extension is debugging this browser” banner during capture — an unavoidable cost of using CDP, and mildly alarming the first time you see it. Second, there’s no multi-viewport import like html.to.design’s; you resize the window and capture each breakpoint separately. Third, the free tier is 5 conversions per month — fewer raw imports than html.to.design’s free tier. There are no feature gates on free, though, and no sign-up at all. Pro is $9/month.
It’s on the Chrome Web Store if you want to poke at it.
Builder.io’s open-source plugin. Being completely free makes it the zero-commitment way to try this category, and the source is public — worth reading if you’re curious how these tools work internally.
Output quality depends heavily on the page. Simple layouts come through fine; on complex pages I hit misplaced elements and dropped styles. There’s no post-processing either — no Local Styles generation, no careful Auto Layout reconstruction. It’s a side project next to Builder’s main product (Visual Copilot), and the pace of improvement reflects that.
Fine for occasionally moving a simple page. The variance makes it hard to put in a real pipeline.
The differences between these tools come down to how each one reads the DOM:
getComputedStyle (Builder.io) is the simplest to implement but tends to miss pseudo-elements and shadow DOM boundaries.If you check “how does it read the page” first, you can rule out the wrong tool for your situation quickly.
| Situation | Pick |
|---|---|
| Multi-viewport imports, batch-migrating many pages | html.to.design |
| Pages behind auth, localhost, no third-party transit allowed | html2figma |
| Occasional simple pages, zero budget | Builder.io |
| Full redesign — you’ll redraw everything anyway | Skip the tools; a reference screenshot may be faster |
That last row is sincere. Converted layer structures earn their keep when most of the existing UI survives the redesign. If you’re razing everything, a pinned screenshot for reference often beats inheriting someone else’s layer tree. All three have free tiers — the most reliable test is to run one page you know well through each and compare the layer trees yourself.