There's a particular kind of satisfaction in pasting a web address and watching the whole page land in Figma — not as a flat picture, but as layers you can pull apart. No saving files, no copying markup, no rebuilding by eye. Most of the time it really is that simple. The times it isn't usually have a single cause, and it has a name: CORS.
URL import renders a live page in a real browser frame and rebuilds it as editable Figma layers. Some pages block a direct fetch — a rule called CORS — but a built-in proxy clears most of them, and saving the page is the reliable fallback for the rest.
What URL import actually does
Paste an address and a few things happen in quick succession. The page is loaded in a real, sandboxed browser frame — a genuine render, with the stylesheets applied, the fonts resolved, the layout settled. Then the importer reads what the browser computed: the position and size of every block, the colour and weight of every run of text, the source of every image.
From those measurements it rebuilds the page as native Figma nodes — a frame for each section, live text you can retype, photos as image fills, icons as vectors — and places the result on your canvas.
That's a different thing from copying markup by hand, where you'd be translating tags and CSS into shapes yourself and hoping the spacing matched. Here nothing is transcribed. The page is measured from the real render and reconstructed from those numbers — which is also how the markup-only path works when you paste raw HTML and CSS. URL import just fetches the page for you first.
Why some URLs fail: CORS, in plain English
Now the exception. Every so often you paste a perfectly ordinary address and the import stalls or comes back empty. The culprit is almost always CORS — Cross-Origin Resource Sharing — and it's worth understanding, because once you can name it, the error stops being mysterious.
Browsers have a standing rule: a script running on one site is not allowed to quietly read the contents of another. It's there to stop a malicious page from siphoning your logged-in bank session or your webmail. So when the plugin tries to fetch a page from a domain that hasn't opted in, the browser refuses on principle.
That refusal is the web working as designed — a security feature, not a bug in the plugin. The page isn't broken and neither is the importer. The two are simply separated by a wall the browser is meant to keep up.
CORS isn't the plugin failing. It's the browser doing exactly what it's supposed to — keeping one site from reading another.
How a proxy gets you past it
The way around a wall like this is to stop asking the browser to climb it. Instead of the plugin reaching across origins itself, the blocked request is relayed through Vellum's own server: the server fetches the page — server-to-server requests aren't bound by the browser's same-origin rule — and passes the result straight back to the plugin to rebuild.
To you it's invisible. You paste the same URL; the import simply works, with the detour handled in the background. This is what clears the large majority of pages that a direct fetch can't touch.
A fair question is what the proxy does with your page on the way through. The honest answer is: nothing it doesn't have to. A well-behaved proxy fetches the page, hands it back, and keeps no copy — it doesn't store the content or log what you imported. It's a relay, not a record.
When a page still won't import
A proxy clears most walls, but not all of them. A handful of pages will still refuse, and the reasons are usually mundane:
- The site is down or timing out. If the page won't load in your own browser, it won't load for the importer either.
- It actively refuses automated requests. Some sites detect anything that isn't a person clicking and block it outright, proxy or not.
- A wall sits in front. A cookie or consent banner, a paywall, or a login screen means the real page never renders — the importer only ever sees the gate.
When that happens, there's a fallback that almost never fails, because it sidesteps the network entirely. Open the page in your own browser, where you're already past any login or consent screen, then use Save As → "Webpage, Complete" and drop the saved .html file into the plugin instead. The page you already have on screen becomes the source. That whole route — and when to reach for it — is covered in importing a website into Figma.
Getting a clean URL import
Assuming the page does load, a few habits make the difference between a tidy import and a messy one:
- Pick the right width first. Choose desktop, tablet, or mobile before you import — the page is measured at that width, and a layout captured at the wrong one won't reflow to fit later.
- Clear cookie banners. If a consent overlay covers the page, it'll be sitting on top of your import too. Dismiss it before the page is traced.
- Let heavy pages settle. Content-rich pages with lazy images or fonts that arrive late need a moment. What's on screen at the instant of the trace is what comes across, so give it time to finish drawing.
- Prefer the canonical URL. Paste the page's real address rather than a shortened link or a redirect chain — fewer hops, fewer surprises.
These same instincts pay off when you're pulling a page apart to study it — spacing, type, colour — rather than just bringing it in. If that's your aim, recreating a website in Figma for a teardown goes deeper on reading a design from its layers.
The bottom line
URL import is the fastest way into Figma when it works — and it works far more often than the word "CORS" might lead you to fear. A real render, measured and rebuilt as editable layers; a proxy to quietly clear the pages that resist; and a save-the-file fallback for the stubborn few. Paste the address first. Keep the saved-page trick in your back pocket for the rest.