Why does html.to.design return flattened images instead of editable layers on some sites?

html.to.design's renderer runs on its servers and pulls the HTML from outside your browser session. Modern React, Vue, and Svelte apps return an almost-empty shell on first request and only paint content after JavaScript executes. The renderer often captures that intermediate state — which it then rasterizes — rather than the fully-painted page. Export to Figma reads the resolved DOM after JS has run in your Chrome tab, so the same site produces editable layers.

Can html.to.design import a page that's behind a login?

No. html.to.design fetches the URL from its own infrastructure and has no way to access your authenticated session. Anything behind a paywall, signin, or feature flag fails. Export to Figma uses your existing Chrome session — if you can see it in your browser, you can capture it.

How much does html.to.design cost compared to Export to Figma?

html.to.design is a paid Figma plugin with limited free uses, then subscription pricing for unlimited imports. Export to Figma offers 10 free captures every month with no card required, and Pro is currently $1/month (launch promo) for unlimited. For an individual designer doing occasional work, Export to Figma's free tier is enough. For an agency, Export to Figma's Pro is significantly cheaper than html.to.design's equivalent plan.

Does html.to.design support Tailwind-based sites well?

Tailwind specifically isn't the issue — Tailwind compiles to plain CSS that any renderer handles. The issue is that Tailwind sites are often paired with React or Next.js, which means heavy client-side rendering. On those sites, html.to.design's server fetch sees a near-empty HTML shell. Export to Figma captures the painted result in your browser, so Tailwind + React sites convert cleanly.

How long does an html.to.design import take vs Export to Figma?

html.to.design typically takes 10–60 seconds per page depending on its server queue and the page's complexity. Export to Figma captures in 2–5 seconds for marketing pages because there's no queue and no separate render step — the DOM is already painted in your browser.

If I switch from html.to.design to Export to Figma, do I lose anything?

Nothing already imported into Figma is affected. Both tools produce native Figma layers, so files captured with either remain editable independent of the tool. Switching only changes how new captures happen going forward.

html.to.design Alternative: Export to Figma (Free Chrome Extension)

TL;DR

html.to.design is the most polished Figma plugin in the web-to-Figma space — paste a URL inside Figma, wait, get layers. Export to Figma is a Chrome extension that captures the same kind of result from inside your browser instead.

If your captures are mostly static marketing pages and you prefer staying inside Figma, html.to.design works well. If you hit any of the following — modern React/Vue apps returning flat images, sites behind a login, frequent captures stacking up against the paid plan, or anything generated by AI app builders — the extension model fixes all of them.

Quick comparison

	Export to Figma	html.to.design
Where it runs	Chrome extension	Figma plugin
How URLs get resolved	Your Chrome session (DOM after JS)	Their servers (HTML before JS in many cases)
Captures behind login
Modern JS-heavy sites (React / Vue / Svelte)		Variable
AI-generated app previews		Variable
Element-level capture		(whole page)
Free tier	10 captures / mo, no card	Limited trial
Time per capture	2–5 sec (no queue)	10–60 sec (server queue)
Lives in Figma	(paste step)

When html.to.design is the right pick

It's worth being honest about this — html.to.design has been the leader in this space for a while and there are real reasons to use it:

You strongly prefer working inside Figma. html.to.design runs as a Figma plugin. You never leave the app. Paste a URL into the plugin, wait, and the page appears in your canvas. If your entire workflow is in Figma and you only import the occasional site, that's a real ergonomic advantage.
The sites you import are mostly static marketing pages. Plain HTML/CSS marketing pages (no React, no auth, no dynamic content) convert cleanly through html.to.design's server renderer. If your work is mostly landing pages, brochureware, and content sites — both tools produce comparable output and your choice comes down to ergonomics + price.
You're already paying for it and not capturing frequently. If you're on an html.to.design plan and you import a handful of sites per month, you're getting your money's worth. The switch isn't urgent.

When Export to Figma is the better pick

Export to Figma exists because three patterns kept breaking html.to.design for designers I worked with:

1. Authenticated content

html.to.design pulls URLs from outside your browser. That means anything that requires you to be signed in — your own SaaS dashboard, an admin view, a member-only page, a customer portal — is unreachable. The plugin sees the public-facing login wall, not the actual UI.

Export to Figma runs inside Chrome alongside your normal browsing. If you're already signed in (and you usually are), capturing the logged-in view is identical to capturing a public page. For designers redesigning internal tools or SaaS dashboards, this is the difference between can do the project and can't do the project.

2. Modern JavaScript apps

React, Vue, Svelte, Next.js — the modern web ships almost-empty HTML on the first request, then paints content client-side. html.to.design's renderer often captures the intermediate state and rasterizes whatever's visible. The result lands in Figma as a flat image instead of editable layers.

Export to Figma reads the DOM after the browser has finished painting. The result is editable text, real shape layers, and named hierarchy — even for heavy SaaS UIs.

3. AI-generated app builders

This is the newer wedge. Lovable, Bolt.new, v0.dev, Cursor, Vercel — all of them produce React apps with aggressive client-side rendering. They're the worst-case scenario for server-side fetch tools. Export to Figma is specifically tested against the top AI app builders every release. html.to.design handles them inconsistently.

If your workflow includes polishing AI-generated apps in Figma before handoff — see the dedicated Lovable & Claude Code use case — Export to Figma is built for that.

Where they differ in practice

Speed

html.to.design's capture is server-side: paste URL, plugin queues the request, server fetches and renders the page, output streams back to Figma. Typical wall-clock time: 10–60 seconds depending on the queue depth and the page's complexity.

Export to Figma is in-browser: click the extension, the resolved DOM is captured directly, paste into Figma. Typical wall-clock time: 2–5 seconds. There's no queue because there's no server hop.

For one-off captures the speed gap doesn't matter. For an agency doing competitive audits across 15 sites in a sprint, the cumulative time difference is meaningful.

Element-level capture

A common designer workflow is "I just want this hero" or "I just want this pricing block" — not the whole page. html.to.design captures whole pages; you trim in Figma after.

Export to Figma supports element-level capture. Click the extension, hover over an element on the page, click. Only that element comes into Figma as its own frame, with its own auto-layout intact.

Pricing

html.to.design is a paid Figma plugin. There's a limited trial, then per-month tiers for unlimited imports. The numbers move so I won't pin a specific dollar figure — check their site for current pricing.

Export to Figma's tiers:

Free: 10 captures per month, forever, no credit card.
Pro: $1/month during the launch promo. Unlimited captures.

For an individual designer doing occasional captures, Export to Figma's free tier is enough — you may never need to upgrade. For agencies and teams doing frequent captures, the Pro tier remains meaningfully cheaper than html.to.design's equivalent plan.

How to switch (it's painless)

There's no data migration, no export, no setup beyond installing the extension:

Install Export to Figma from the Chrome Web Store.
Pin the extension to your Chrome toolbar so the icon stays visible.
The next time you'd reach for the html.to.design plugin, click the extension icon in Chrome instead.
Paste into Figma with Cmd+V / Ctrl+V.

Everything you've already imported into Figma via html.to.design is unaffected — both tools produce native Figma layers that live in your files independent of which tool created them.

You can keep html.to.design installed if you want both options. Many designers do, using each for the case it handles best.

A real workflow: SaaS dashboard audit

A designer I worked with had a redesign brief for a SaaS company's internal admin tool. Twenty-five pages, all behind login, plus their public marketing site.

With html.to.design, the marketing pages went smoothly. The admin tool was completely unreachable — the plugin fetches URLs from its own servers and the login wall was the only thing it could see. The designer ended up taking screenshots of each admin page and pasting them into Figma as flat images, then manually retyping every label and rebuilding every shape. Two days of busywork before the design phase even started.

With Export to Figma, the same designer signed into the admin tool in Chrome (which they'd already have done anyway), captured each page with one click, and was designing on top of editable Figma layers within an hour.

That's the gap. For static marketing-only work, the two tools are close. For anything authenticated, dynamic, or AI-generated, the Chrome-extension approach is the only one that consistently produces editable output.