UnHTML vs Anima: Which Direction the Conversion Actually Runs

UnHTML and Anima solve opposite problems

UnHTML converts a webpage into Figma layers. Anima converts a Figma design into code. Two different jobs. They get lumped together because both touch Figma and both can start from a URL, but the conversion runs in opposite directions on the same pipeline. Confuse them and you'll pick the wrong tool for the job you actually have.

That mix-up matters more than it sounds like it should. A designer inheriting a site with no design file needs the webpage-to-Figma direction. A team that already has a Figma file and needs a working front end needs the Figma-to-code direction. Searching "anima alternative" or "unhtml vs anima" usually means someone hit the wrong tool first: tried to export code from a page that was never in Figma, or tried to import a webpage into a plugin that only reads Figma files. Here's what each tool does, where the two workflows actually overlap, and where pricing pulls them apart.

What UnHTML does

UnHTML takes a live webpage and turns it into native, editable Figma layers: real frames, text, images, vectors, and auto-layout mapped from the page's own CSS. The output is a Figma file. Nothing about it produces code.

It runs offline by default, zero network requests under default settings. Fetching remote assets and running page scripts is a single opt-in, off unless you switch it on, so nothing leaves your machine otherwise.

Pricing is a one-time purchase, not a subscription. Free imports up to 500 layers using absolute positioning. Pro is $39 one-time per editor, removes the layer cap, and adds auto-layout conversion. Studio is $119 one-time and covers five editors.

Import isn't pixel-exact, and it doesn't try to be. Fonts that aren't installed locally get substituted, Inter by default, and every swap shows up in the import report instead of silently changing the design. Complex grids that can't be represented as Figma auto-layout fall back to absolute positioning rather than producing a layout that looks right until someone resizes a frame.

What it doesn't do: no code export, no React, no HTML output. If the goal is shippable front-end code, this isn't the tool. It's also not a design tool for building something new. It's a way to get an existing page into a format Figma can edit.

What Anima does

Anima's core product runs the other direction: a Figma design goes in, code comes out. The Anima Figma plugin exports a selection from an existing Figma file to React, HTML, CSS or Tailwind, Vue, TypeScript, Next.js, and more, working from a file already built in Figma. The Anima Playground offers the same export starting from a pasted Figma link, aimed at fast prototypes and people who aren't designers.

Anima also has a Clone website feature, and this is the part that causes the mix-up. Clone website takes a live URL, the same kind of starting point UnHTML uses, but it produces code, HTML or React, not Figma layers. The entry point looks similar; the exit point is the opposite. If the goal is an editable Figma file, Clone website won't get you there.

Easy to miss why, since both tools can technically start from "a URL." What matters is what comes out the other end. Anima's own material frames the product around teams building full applications from an existing Figma design, not around recreating a page that has no Figma file to begin with. It's a design-to-code tool with a website-cloning shortcut bolted on, not a website-to-design tool.

How the auto-layout conversion actually works

The reason a webpage-to-Figma conversion can hold up at all comes down to how closely Figma's auto-layout engine now mirrors CSS. Figma's own guidance on using auto-layout with CSS Flexbox in mind describes padding, gap, and fill-container sizing as following the CSS border-box model. A padded element still gets the room it needs rather than being compressed, and children set to fill container distribute space by their content area rather than by their own size, the same way border-box sizing works in CSS.

Spacing lines up too. Figma's auto-spacing values Between, Evenly, and Around correspond directly to the CSS values space-between, space-evenly, and space-around. The CSS gap property is itself a shorthand for row-gap and column-gap on flex and grid containers, and it's this property, read straight off the page's stylesheet, that gets mapped into a Figma frame's gap value.

Where a layout can't be reproduced faithfully, complex grids, non-standard stacking, the fallback is absolute positioning instead of guessing at a structure. A deliberate limit, not a bug: an honest fallback beats a layout that looks right and breaks the moment someone touches it.

That limit is also why the two tools can't simply swap roles. Anima's plugin reads a Figma frame's own auto-layout settings and writes them out as flexbox CSS, a translation that works because Figma already stores the layout in a structured, inspectable way. Going the other direction means reading a rendered page's computed CSS and reconstructing what auto-layout settings would reproduce it. Reading structured data and writing CSS is a narrower problem than reading a live page's rendered styles and reconstructing structure from them. Part of why these ended up as two separate products instead of one that does both.

Pricing: one-time versus subscription

Anima's pricing page discloses the Free tier's daily caps and the Enterprise floor, but doesn't publish a fixed price for a standard per-seat paid plan as of this writing. That number stays unverified rather than guessed.

The practical split: someone importing a page occasionally pays once and is done. A team exporting code continuously is carrying a subscription that scales with how much they use it, regardless of which specific plan they land on.

When you'd actually use both

The two workflows chain in one direction and one direction only. Import an existing page into Figma, redesign it there, then hand the finished file to Anima to export the redesigned version as code. A real, common path: teardown, redesign, ship. A team rebuilding a legacy page, or tearing down a competitor's page to see how it's put together, gets an editable starting point without redrawing every frame by hand, then hands the result to whatever code-export tool the front-end team already uses.

Going the other way, Figma to code and back to Figma, doesn't make sense. It just re-imports what already existed. If a design already lives in Figma, there's nothing to convert, and running an import against a page rendered from that same Figma file would just reconstruct a copy of a file the team already has.

The direction is the whole answer

UnHTML and Anima aren't competing for the same job. One turns a webpage into an editable Figma file; the other turns a Figma file into code. Pick the first when the destination is Figma. Pick the second when the destination is shippable code. Most projects that need both will use them in that order, not as alternatives to each other.