UnHTML vs Locofy: Design to Code and Web to Design Are Not the Same Job

What job each tool actually does

UnHTML and Locofy get compared often, but they solve different problems. UnHTML takes a live webpage and imports it into Figma as native, editable layers. Locofy takes a Figma design you already built and exports it to code. One captures, the other ships. If you only need one of those two steps, the other tool won't cover it.

UnHTML accepts a self-contained HTML file, a Safari .webarchive, or a scene.json captured through its CLI, then converts the page into real Figma frames, text, images, vectors, and auto layout, mapped from the page's own CSS. By default it makes zero network requests: the import runs entirely on your machine. Fetching remote assets and running page scripts, which matters for JavaScript-rendered pages, is a single opt in that stays off unless you turn it on. The only call UnHTML makes on its own is a weekly licence check carrying the licence key and a Figma user ID. The opt in requests setting governs everything else.

Locofy starts on the other side of the process. It reads an existing Figma file, whether authored by hand or produced by a capture tool, and exports it to React, React Native, HTML and CSS, Flutter, Vue, Angular, or Next.js, through either an automatic Lightning mode or a step by step Classic mode with manual tagging. Locofy Lightning is genuinely fast at turning a tagged Figma file into working framework code, and its framework list, seven options as of 2026, is broader than most design to code tools attempt. What it can't do is start from a live URL. There's no capture path in the product: a Figma file has to already exist before Locofy has anything to export.

Where the two workflows meet

The overlap shows up in one specific situation: a team wants to redesign a page and has no Figma file to start from. That happens with legacy sites that predate any design system, and it happens when a team studies how a competitor built a page before designing its own version.

Here the sequence matters. A capture tool has to run first, because there's nothing yet for a code exporter to read. Once the page exists as editable layers, with real auto layout instead of a flat image, the team can redesign inside Figma and then hand the finished file to a design to code tool.

Studying a competitor's page this way means analyzing its structure, its component boundaries, its spacing decisions, so your own team can make informed choices. It doesn't mean republishing someone else's design as your own finished work. The goal of a teardown is understanding, not duplication.

The same sequence applies to a page you own but never had a design file for. A lot of production sites were built directly in code years before anyone set up a Figma workspace for them. Capturing that page as it actually renders today, with its real CSS instead of a rough visual guess, gives the redesign a working starting point instead of a blank canvas.

Pricing and packaging side by side

The two products price differently because they solve different problems. One is a per-import capture tool. The other is a recurring code-export subscription.

UnHTML's numbers above come directly from unhtml.pro, checked 2026-09-29. Locofy's figures don't have that same footing: locofy.ai/pricing renders its pricing table client side, and two independent reviews of the page reported the same numbers, but neither is the vendor's own static page. Treat the Locofy figures as unverified until you check the live page yourself before making a purchasing decision.

The structural difference matters more than the exact dollar amounts. UnHTML charges once per editor and you own the license. Locofy charges monthly for continued access to its export frameworks.

The CSS to auto layout mapping, property by property

Converting a webpage into a usable Figma file means reading the page's real computed styles and reproducing them as Figma auto layout properties, not guessing at a visual approximation.

The core mapping, per MDN's flexbox reference:

• CSS flex-direction (row or column) maps to a Figma auto layout frame's horizontal or vertical flow.
• CSS justify-content maps to alignment along Figma's primary axis.
• CSS align-items maps to alignment along Figma's counter axis.
• CSS gap maps directly to Figma's gap value between objects in the frame.
• CSS padding on the container maps to the auto layout frame's padding.

Figma's grid flow works differently from its horizontal and vertical auto layout. It groups objects into columns and rows with spans, closer to CSS Grid than flexbox. A page built with CSS grid maps into that grid flow rather than into a flex-style frame, which is why a capture tool has to detect which layout model a container actually uses before it can pick the right Figma structure.

UnHTML reads flex, grid, and block layouts off a page's actual CSS and builds the corresponding auto layout structure. When a layout can't be reproduced faithfully, the frame falls back to absolute positioning rather than an approximation that would look right but behave wrong when resized. It's not a pixel exact clone of the source page, and the import report lists exactly what fell back and which fonts got substituted, Inter by default when a font isn't installed locally.

This matters for the workflow described above. A design to code tool like Locofy exports whatever structure the Figma file already has. If that structure is flat, absolutely positioned layers, the exported code will be too. A properly mapped auto layout file, the kind a capture tool that reads real CSS produces, gives a code exporter something actually worth exporting.

When to reach for UnHTML first, Locofy second

For a page with no existing Figma file, capture it before you design anything. That covers three common situations: a legacy site with no design source at all, a competitor teardown done for reference, and a redesign of your own aging page. In each case, running the live page through UnHTML gets you real, editable layers with working auto layout, not a flat screenshot traced by hand.

Know the limits going in. The free tier caps out at 500 layers per import; complex pages with deep component nesting may hit that ceiling before Pro removes it. Fonts that aren't installed locally get substituted, and every substitution shows up in the import report, so nothing is silent. Complex CSS grids that don't map cleanly fall back to absolute positioning. None of that makes the result unusable. It makes it honest about where automation stops and manual cleanup starts.

Once the redesigned file is ready, that's where a design to code tool takes over. Locofy, or any comparable exporter, reads the Figma file you now have and turns it into framework code. The two tools are stops on the same pipeline, not two versions of the same stop.

Conclusion

UnHTML and Locofy answer different questions. UnHTML answers "how do I get this existing webpage into Figma as real layers." Locofy answers "how do I turn this Figma design into working code." Neither one substitutes for the other, and a project that starts with no design file at all needs the capture step before the export step has anything to work with.

As design to code tools keep adding frameworks and getting faster, the quality of the Figma file feeding them stops being a minor detail. A capture step that reads a page's actual CSS and builds real auto layout, instead of flattening everything to absolute positions, is what makes the export step downstream worth running at all.