UnHTML vs html.to.design: Pricing, Layer Limits, and Auto Layout Output in 2026
UnHTML and html.to.design both turn a web page into editable Figma layers, but they price and cap that conversion in very different ways.
Choosing between UnHTML and html.to.design mostly comes down to two questions: how each one caps its free plan, and how it charges you for removing that cap. UnHTML's free tier is capped by layer count, and its paid tier is a one-time purchase per editor. html.to.design's free tier is capped by import frequency, and its paid tier is a recurring subscription. Both convert a live web page into Figma layers using auto layout where they can, then fall back to absolute positioning where they can't. What follows checks pricing, limits, and output behavior against each vendor's own pages as of the date this article was written.
Pricing Model: One-Time Purchase vs Monthly Subscription
UnHTML sells a license, not a subscription. The free plan costs nothing and imports up to 500 layers, for personal use only. Pro is a one-time payment of 39 USD per editor that removes the layer cap, permits commercial use, and includes a year of updates. Studio extends Pro to up to five editors on a team for a single 119 USD payment, with priority support thrown in. Those figures come straight from the pricing section of the product's own site, so treat this article's numbers as a snapshot and re-check before you buy.
html.to.design takes the opposite approach: it charges per user, per month. The free plan requires no card and allows up to 10 imports every 30 days. Pro runs 12 USD a month billed annually, or 18 USD billed monthly, per user, with unlimited imports under a fair use policy capped at 1,000 imports a month. Teams that outgrow even that get pointed toward a separate API product rather than a higher subscription tier.
The practical difference isn't just the sticker price. UnHTML's Pro purchase is a fixed cost a single designer pays once and keeps for as long as the license terms allow. html.to.design's Pro plan is an ongoing cost tied to how many months you keep the seat active. If you expect to use either tool for more than a couple of months, weigh the one-time fee against several months of subscription, not against a single month's bill. Scale that to a team of five and the math shifts further: UnHTML's Studio tier is one 119 USD payment, full stop, while five html.to.design Pro seats renew every month for as long as the team keeps them.
Free Tier Limits: Layer Count vs Import Frequency
The two free tiers are capped on different axes, and that difference matters more than it sounds.
UnHTML's free plan is bounded by layer count: up to 500 layers per import, no matter how many times you import in a day or a month. A single large, deeply nested page, say a marketing site with a long footer and a busy component library, can hit that cap in one go. Once Pro removes the cap, layer count stops being a factor at all.
html.to.design's free plan is bounded by import frequency instead: 10 imports every 30 days, with no published layer limit for any individual import. Its documentation doesn't describe a per-import ceiling on layers, frames, or nesting depth, only the monthly allowance. A small page imported ten times counts the same against that cap as a large page imported ten times.
So the real question is about your workflow, not just the sticker price. Import one large, complex page and spend a while working on it, and UnHTML's free tier is the one you'll outgrow first, in a single import. Import many smaller pages repeatedly while iterating on a design system or auditing a site section by section, and html.to.design's ten-imports-per-month cap is the one you'll hit first, regardless of how big any single page is.
How Each Tool Maps CSS to Figma Auto Layout
Both tools target the same destination: Figma's native auto layout system, which arranges child objects along a direction, with a gap between them and padding around them, and resizes them according to hug, fill, or fixed settings.
That system maps closely to CSS. Direction corresponds to flex-direction. Gap corresponds directly to the CSS gap property. Resizing behavior mirrors flex-grow, flex-shrink, and flex-basis. On the CSS side, justify-content distributes space along the main axis while align-items aligns items along the cross axis, and gap sets fixed spacing between items rather than distributing whatever space is left over.
For a page built with display: flex and explicit justify-content, align-items, and gap values, both tools have a clean auto layout target to map to: direction becomes the frame's horizontal or vertical flow, gap becomes the frame's gap setting, and padding on the source element becomes padding on the frame. The harder cases, CSS grid with complex spans, absolutely positioned overlays, elements sized by content in ways auto layout can't express, are where the two tools diverge in how gracefully they degrade. Reading the import report matters more than trusting the canvas at a glance here.
Repeated structure is the other half of the mapping. A page that repeats the same card, button, or list item many times gives an import tool a chance to notice the pattern and turn it into something reusable instead of a pile of one-off frames. Whether repeated elements become components and repeated type becomes shared text styles, or whether every instance stays a flat, disconnected frame, is a distinction that shows up after the import, once you actually start editing.
Fallback Behavior and Output Fidelity
Neither tool claims to reproduce a page exactly. UnHTML states plainly that a frame that can't reproduce the captured geometry falls back to absolute positioning on its own, so a section that defeats auto layout still lands in Figma, just without the resizing and reflow benefits auto layout brings. That fallback is close to how Figma's own "ignore auto layout" setting works: an object positioned that way behaves like CSS position: absolute inside its parent frame, sitting outside the automatic flow rather than resizing with it.
This matters for expectations. If a competitor's marketing implies an exact, pixel-for-pixel clone of a source page, treat that claim as unverified unless the vendor's own documentation says so directly, and stay skeptical even then, since geometry that defeats auto layout has to fall back to something. What both UnHTML and html.to.design actually promise is editable, real Figma layers, with graceful degradation on whatever auto layout can't express, not a perfect visual copy. Font substitution follows the same logic: a font that isn't installed locally gets swapped for a default, and a careful import tool reports every substitution rather than quietly rendering the wrong typeface.
Which One Fits Your Workflow
UnHTML's Pro tier consolidates what it imports: repeated elements become real components, repeated type becomes shared text styles. That suits a designer or a small team, up to five editors on Studio, doing occasional teardown or rebuild work where a fixed cost matters more than a monthly bill.
html.to.design's Pro tier is built around doing the same import again: bulk URL imports, a fast re-import path for pages you check on a recurring basis, and high-resolution image detection for pages with heavy imagery. That suits a team that revisits the same live pages on a schedule, competitive audits, a design system refresh across many pages, or ongoing QA against a live site, where an active subscription buys ongoing convenience rather than a single conversion.
Neither tool is the obvious answer for every situation, though. A freelance designer doing a handful of one-off teardowns a year may never need to pay either vendor at all, staying under html.to.design's ten-imports-per-month free cap or working within UnHTML's 500-layer free ceiling one page at a time. It's the recurring, high-volume workflow, or the single large page a free tier can't hold, where the paid tiers start to matter, and where the pricing model difference stops being academic.
Check both vendors' own pricing pages before deciding. Prices, import caps, and fair use terms are the kind of detail that changes between a plugin's releases, and this comparison reflects what each vendor stated as of the date it was checked.
Conclusion
The short version: UnHTML caps its free plan by layer count and charges once per editor to remove that cap. html.to.design caps its free plan by import frequency and charges monthly per user for more headroom. Both map CSS layout to Figma auto layout and fall back to absolute positioning on geometry auto layout can't express, so neither is a pixel-exact clone of the source page. For current figures before you commit to either one, check UnHTML's pricing page directly.
Questions
- Is UnHTML cheaper than html.to.design?
- It depends on how long you keep using it. UnHTML Pro is a 39 USD one-time purchase per editor, so a single designer who keeps the license for more than about two months already pays less than html.to.design's 12 to 18 USD per month subscription. html.to.design has a free tier with no credit card required, so occasional users who stay under 10 imports every 30 days pay nothing either way.
- What is the free tier layer limit in UnHTML?
- UnHTML's free tier caps each import at 500 layers and uses absolute positioning rather than auto layout. Paying for Pro, a 39 USD one-time purchase per editor, removes the layer cap entirely rather than moving to a higher numeric ceiling.
- Does html.to.design have a layer limit?
- As of the date this article was checked, html.to.design's published documentation does not state an explicit layer count cap. Its free and Pro tiers are instead bounded by import frequency: 10 imports every 30 days on the free plan, and 1,000 imports per month under Pro's fair use policy.
- Do UnHTML and html.to.design produce pixel-exact output?
- No. Both tools convert CSS layout into Figma's native auto layout system where they can, and fall back to absolute positioning for geometry that auto layout cannot reproduce. That fallback behavior means neither tool guarantees an exact clone of the source page, and any claim to the contrary should be treated as unverified.