Search "HTML to Figma plugin" and you'll find a dozen of them, all promising the same thing in the same words. They don't all deliver the same thing. The difference that matters isn't the marketing — it's what you get when you click into the result.
The biggest divide between HTML-to-Figma plugins is whether they flatten the page into an image or rebuild it as editable layers. Judge any plugin on six things: editable output, measurement accuracy, font handling, URL/CORS support, detail fidelity, and honesty about limits — then test it on a page you know.
The one test that settles it
You can read every feature list on every listing page and still not know what a plugin actually does. There's a faster way. Import a page, then click into the result.
If you can select the headline and retype it, you're holding a layer tree — real frames, real text, real fills. If you click and the whole page selects as a single object, it's a screenshot with a frame around it. That one gesture sorts every plugin in the category into two piles, and the piles behave nothing alike.
| What to check | Flatten-to-image plugins | Layer-rebuilding plugins |
|---|---|---|
| The result | One flat picture on the canvas | Frames, live text, image fills, vectors |
| Can you edit it? | No — it's an image | Yes — every node is editable |
| Fidelity | Looks right, but frozen | Measured from the real render |
| Best use | A quick visual reference | Redesigns, audits, reuse |
Neither pile is wrong in the abstract. A flat picture is a perfectly good reference if a reference is all you wanted. But if you imported the page to work on it, the distinction is the whole decision.
Six things to check
The click-into-it test tells you which pile a plugin sits in. These six criteria tell you how good it is once you're in the right pile. Run down them with any candidate in front of you.
- Editable layers, not a flat image. This is the dividing line, so check it first. A flat image can't be restyled, recoloured, or pulled apart — you can only trace over it. Editable layers are the thing you came for: text you can retype, fills you can change, frames you can move. Everything else on this list assumes you've cleared this bar.
- Measured, not guessed. A good plugin reads the browser's real computed layout — actual positions, sizes, and font weights as the page was rendered — rather than approximating from the source. The difference shows up in the details: does a button land where it really sits, or a few pixels off? Guessed layouts drift; measured ones don't.
- Font handling. When a page uses a font you don't have installed, something has to give. The honest behaviour is to tell you what was substituted, so you can decide what to do. The frustrating behaviour is a silent swap that lets the text re-wrap and overlap its neighbours, leaving you to discover the damage later. Ask which one you're getting.
- URL and CORS. Can the plugin import a live URL directly, or only code you've already pasted? Direct URL import is far less fiddly — but many pages block cross-origin requests, so a plugin that imports URLs well needs a built-in proxy to reach them. Without one, "URL import" quietly fails on exactly the pages you most want.
- Detail fidelity. The gap between tools lives in the small things: per-side borders, gradients, shadows, blurs, inline SVG brought in as real vectors. Lesser tools drop these — a four-sided border becomes one, a gradient flattens to a solid, an icon arrives as a blurry raster. Check a fiddly element and see how much survives.
- Honesty about limits. Every plugin has gaps — a font it can't load, canvas or WebGL content it can't read. The ones worth trusting name those gaps plainly. The ones to avoid quietly fake them: a baked-in placeholder where the real thing should be, dressed up to look like it worked. A tool that tells you what it couldn't do is doing you a favour.
How to actually test a plugin
You don't need to take anyone's word for any of this, including mine. Five minutes with a page you know tells you more than any feature list ever will.
- Pick a page you know well — ideally one with a tricky bit of layout you can already picture in your head.
- Import it in each plugin you're weighing up, under the same conditions.
- Click into the output and try to edit the text. If you can retype the headline, it's layers; if the page selects as one object, it's an image.
- Check a tricky detail — a per-side border, a gradient, an icon — and see whether it came across as the real thing or a flattened approximation.
- Note what it does when a font is missing: does it tell you what it substituted, or silently swap and let the text shift?
Do that with two or three candidates and the right one usually picks itself. The marketing copy converges; the behaviour doesn't.
Where Vellum sits
To be straight with you: Vellum is in the layer-rebuilding, measured camp. It reads the browser's real render — every position, size, and font weight taken from what the browser actually drew — and rebuilds the page as native, editable Figma layers rather than a flat picture. When it meets something it genuinely can't reproduce, like a non-installed font or a WebGL scene, it names the gap instead of faking it.
I'd rather you test that claim than trust it. Run the click-into-it test above on Vellum, check a fiddly detail, and see what survives. For the longer story of what gets captured and what doesn't, see HTML to Figma, explained; for the practical ways to get a page onto the canvas in the first place, see importing a website into Figma.
Pick by what you'll do with it
The right plugin depends on the job. If you only need a picture to glance at, almost anything will do — even a flat image is fine. But if you mean to redesign, audit, or reuse the page, you need editable layers measured from the real render, and you need a tool honest enough to tell you where it fell short. Don't take that on faith from anyone, including this page. Run the test, on a page you know, and let the result decide.