UnHTML vs Builder.io's Figma Import: Which One Actually Fits the Job

UnHTML and Builder.io's HTML to Figma plugin both claim to turn an existing webpage into editable Figma layers. They are not built for the same job, though. UnHTML is a single purpose webpage to Figma importer. Builder.io's plugin is the import leg of a design to code pipeline whose main business is turning Figma into code, run in reverse. That difference shapes what each one imports from, how far auto layout gets you, and what happens when a section's CSS won't translate cleanly. Every claim below was checked against the vendor's own documentation or product page, dated 2026-10-03, not pulled from a review site or a forum thread.

What each tool actually imports from

UnHTML takes an HTML file, a Safari .webarchive, a scene.json capture, or output from its own open source capture CLI and bookmarklet. The import runs locally. That matters for teardown work and legacy rebuilds, where the source page usually isn't one you control.

Builder.io's plugin works from a live URL. Paste it in, the plugin pulls the page and converts it. Or use a companion Chrome extension to capture specific DOM elements from a page, including pages behind a login, and import just those sections. Builder.io frames the whole workflow around round tripping: get a page into Figma, then later export the result back out as React, Vue, Tailwind, or several other targets, using an AI model paired with an open source compiler to rebuild proper code hierarchy rather than a flat dump. Once a frame is imported, a designer can also re-touch it with natural language prompts before that export step.

That round trip is the point of Builder.io's product. UnHTML has no code export leg at all. It stops once the layers are in Figma, and that's a deliberate scope choice, not a missing feature. For a deeper look at how the direction of the conversion changes which tool is the right pick, see UnHTML vs Anima: Which Direction the Conversion Actually Runs.

Auto layout fidelity: CSS flex and grid

Checked directly on unhtml.pro on 2026-10-03, UnHTML's free tier already includes auto layout mapped from real CSS flex and grid, capped at 500 layers per import. Builder.io states that auto layout support on imported frames is currently in beta, and its own project documentation recommends manually confirming which layers carry autolayout before exporting back to code rather than assuming every imported frame got it.

Figma itself shipped a flexbox aligned rework of auto layout in 2026, and it's worth knowing about regardless of which import tool you use. Padding is now always fully respected, closer to the CSS border box model: a frame can't be narrower than its total padding. Only inside strokes count toward layout math, not outside or center strokes, and a parent's stroke setting no longer changes how a child's stroke is calculated. Auto gap stacks now support space-between and evenly modes that match their CSS namesakes directly. That version becomes the default for newly created frames in July 2026, with both versions toggleable until the legacy option is removed in January 2027.

Grid auto layout, one of Figma's three auto layout flows, maps onto CSS Grid about as directly as any Figma feature does. Rows and columns are called tracks. Fractional (fr) units distribute space proportionally the same way they do in CSS, and row count adjusts to content the way grid-auto-rows does. See Figma's own documentation for the full mapping. For the property level detail on how individual flex and grid properties land in Figma, see CSS Flexbox to Figma Auto Layout: A Property by Property Map and CSS Grid to Figma: What Survives the Conversion to Layers.

When the conversion cannot stay clean

Both vendors are upfront that this isn't a solved problem. UnHTML falls back to absolute positioning automatically whenever a section's geometry can't be reproduced as auto layout, and a node budget guards against runaway layer counts on unusually dense pages. Builder.io's own documentation states plainly that importing HTML into Figma is a best effort process. Iframes and pseudo-elements aren't converted at all. Not every CSS property is supported, and video and animated GIFs are excluded. Fonts that aren't already uploaded to Figma get substituted.

UnHTML does the same thing with fonts: anything not installed falls back to a substitute (Inter, by default), and every swap shows up in the import report, so nothing changes silently. Neither tool claims a pixel exact result. For UnHTML that's a deliberate line: the import report exists precisely because some things do fall back, and the honest framing is "faithful, editable layers," not an exact clone.

Privacy and where your page's content actually goes

For a competitor teardown, or any page you don't control, where the content goes while it's being processed matters. UnHTML's stated default is zero network requests. Nothing leaves the machine unless remote fetching is turned on by the user, and that opt in path runs the fetch in a sandboxed frame with scripts and inline event handlers stripped before anything renders. The only call UnHTML makes on its own, regardless of settings, is a weekly licence check carrying just the licence key and a Figma user id. Not page content.

Builder.io's workflow is URL or DOM capture based by design, since that's how the plugin gets the page in front of its conversion engine in the first place. If local only processing is a hard requirement for a given teardown, that's a real difference between the two, not a minor one.

Pricing and limits

Verified directly on unhtml.pro on 2026-10-03: the Free plan includes auto layout from CSS flex and grid, open source capture tooling, and community support, capped at 500 layers per import. Pro is 39 USD, one time, per editor, and removes that cap, plus adds component and shared text style promotion for repeated elements, multiple viewport presets, an import report with a font substitution log, and a year of updates. Studio extends Pro to five editors for 119 USD.

Builder.io offers free and premium tiers with no credit card required to use the free features. Specific Builder.io tier pricing wasn't published on the pages checked for this article, so no number is stated here. If pricing is a deciding factor, check Builder.io's current pricing page directly before budgeting a team rollout. Either vendor's numbers can change between the date this was written and the date you read it.

Which one actually fits the job

For redesigning a site with no design file, tearing down a competitor's page, or rebuilding a legacy page with nothing but its CSS to go on, a tool built single purpose for webpage to Figma that runs locally fits that job directly. That's UnHTML's whole scope: get the layers in, keep the structure editable, and leave the rest of the design process to Figma itself. For a team already standardized on a Figma to code pipeline, wanting the HTML to Figma step as one leg of a longer round trip back into React, Vue, or another framework, Builder.io's combined offering fits that different job. Especially if that team is already paying for Builder.io's code export side and the import plugin is just the piece that gets them started.

One more practical point. A one time per editor price with no subscription is a different budgeting conversation than a platform tier that bundles import alongside code generation, AI refinement, and hosting. Neither structure is wrong, but they suit different team sizes and different review cycles. Decide which one matches your team before comparing feature lists line by line.

The bottom line

UnHTML and Builder.io aren't really competing for the same task. One is a single purpose webpage to Figma importer that runs locally and is explicit about where it falls back to absolute positioning. The other is a design to code platform whose HTML to Figma plugin is the reverse leg of a pipeline aimed at getting back to code. Auto layout fidelity, privacy posture, and pricing all follow from that difference. Both vendors are honest that none of this reaches pixel exactness, so verify the specific claim that matters most to your workflow against each vendor's own page before you build a process around it.