HTML to Canvas: Bitmap Screenshots vs Editable Figma Layers

"HTML to canvas" is one of those phrases that means two different things depending on who's searching. A front-end developer usually means rendering a DOM element into an HTML <canvas> — the job of libraries like html2canvas. A designer usually means getting a web page onto the Figma canvas so they can work on it.

Both start with HTML. Both end up on something called a canvas. But the results are fundamentally different: one is a flat grid of pixels, the other is a tree of editable layers. Choosing the wrong one costs time, so it's worth being precise.

Meaning 1: HTML to an HTML <canvas> (bitmaps)

How it works

The HTML <canvas> element is a drawing surface: a rectangle of pixels that JavaScript can paint on. Libraries such as html2canvas walk the DOM, read computed styles, and re-draw the page onto a canvas using the Canvas 2D API. The output is a bitmap you can export as PNG or JPEG.

Related approaches produce the same kind of result:

• Browser screenshots — the browser's own screenshot feature, DevTools "Capture node screenshot", or headless browser screenshots.
• SVG foreignObject tricks — embed HTML inside an SVG, draw that into a canvas, export pixels.
• Server-side screenshot services — a headless browser renders the page and returns an image.

When a bitmap is the right answer

Bitmaps are genuinely useful when the image itself is the deliverable:

• "Share as image" buttons — a chart, a receipt, a quote card.
• Visual regression tests that compare pixels between builds.
• Thumbnails and social preview images.
• Bug reports that need to show exactly what the user saw.
• Archiving a page's appearance at a point in time.

In all of these, nobody needs to edit the result. They need to look at it.

Limitations of bitmaps

As soon as you want to work on the captured page, pixels get in the way:

• No editing. You can't change a headline, adjust a gap or swap a color. You can only paint over it.
• No text. Text is pixels. You can't select it, search it, check its font size or copy it into a spec.
• Blurry when scaled. A bitmap has a fixed resolution. Zoom in, or place a 1x capture on a high-density display, and edges soften.
• No structure. There are no frames, no hierarchy, no spacing values to inspect. A button and the background behind it are the same layer.
• No responsiveness. A screenshot at 1440 is only ever 1440. You need a separate capture per width, and none of them can be resized meaningfully.
• No design system. Colors and type can't be turned into variables or styles, and repeated elements can't become components.
• Fidelity gaps (for re-renderers). Libraries that re-draw the DOM onto a canvas reimplement CSS in JavaScript, so newer or less common CSS features may render differently from the real browser.

Meaning 2: HTML onto the Figma canvas (editable layers)

How it works

In Figma, "the canvas" is the infinite workspace where your frames live. Putting HTML on the Figma canvas means converting the rendered page into native Figma objects: frames, text layers, vectors and image fills.

That's what HTML to Frames does. A page is rendered in a real browser, its geometry and computed styles are measured, and the plugin rebuilds it in Figma as:

• nested frames that mirror the page structure, with Auto Layout where it can be verified,
• real text layers with mixed styles, letter-spacing, line-height and links,
• SVG as editable vectors,
• images as image fills, respecting object-fit and background-size,
• borders, radii, shadows, gradients, blur and blend modes as native properties.

The result is something you can edit, restyle, resize and componentize — not a picture of a page, but a working design file. The HTML to Figma guide covers the full import flow.

When editable layers are the right answer

• Redesigns that start from an existing site.
• Audits of spacing, type and color.
• Design system extraction — color variables, text styles and shadow styles (Pro).
• Handoff and review of pages built in code, including localhost via the Chrome extension.
• Refining AI-generated UI imported over MCP — see AI to Figma.
• Responsive work — Desktop, Tablet and Mobile from one import.

Side by side

The short version: html2canvas gives you pixels; HTML to Frames gives you layers on the Figma canvas.

Why rendering in a real browser matters

Both approaches depend on how faithfully the page is rendered in the first place. Re-drawing libraries like html2canvas run inside the page and reimplement CSS layout and painting in JavaScript. That works well for common styles, but anything the library hasn't implemented — or implements slightly differently — shows up as a mismatch in the image.

HTML to Frames takes a different route. Public pages, local files and pasted code are rendered in an isolated, sandboxed browser, and pages captured with the Chrome extension come from your own browser. Either way, the plugin reads the geometry and computed styles the browser actually produced, then rebuilds them as Figma objects. That's why details that are easy to get wrong come across correctly:

• List markers drawn like Chrome, CSS counters, superscript and subscript.
• Gradients — linear, radial and conic, including px stops and repeating or tiled gradients.
• High-res images from srcset, with object-fit, background-size and tiling respected.
• A single border side in a different color, inner and outer shadows, and text-shadow.

The page is also captured as a normal visitor sees it: cookie banners and popups can be hidden on request, and animations are frozen so the frame is clean rather than caught mid-transition.

What about things that really are canvases?

Here's where the two meanings meet. Some parts of a web page are pixels by nature, and no converter can turn them into meaningful vector layers:

• WebGL and 3D scenes drawn into a <canvas>,
• 2D canvas drawings such as some charts or games,
• iframes, including embedded maps,
• videos without a poster image,
• object and embed elements.

HTML to Frames handles these pragmatically: each one comes in as a screenshot image of that box only. The image sits in the right place, at the right size, inside an otherwise fully editable page. Your hero headline, navigation and cards stay as real layers; only the 3D product viewer or the embedded map is a bitmap.

For animated content, the capture aims for a clean, stable frame: animations are frozen, and WebGL is frozen after a few frames so the scene has time to render something meaningful before it's captured.

This hybrid is usually what a designer wants. You don't redesign the inside of an embedded map; you design the card around it. A screenshot placeholder for the embed, plus editable everything-else, is the practical result.

What isn't converted yet

To be complete about limits: skew and 3D CSS transforms, path() clip-paths, multi-layer masks and Display-P3 colors aren't supported yet. CSS rotation and scale, single clip-path shapes, mask-image, blur and backdrop-blur are. The features page has the full list.

Choosing the right approach

Ask one question: will anyone edit the result?

1. No — it's for viewing, sharing or testing. Use a bitmap. html2canvas or a browser screenshot is simpler and faster.
2. Yes — it's for design work. Use editable layers on the Figma canvas.
3. Mostly yes, but parts are maps, video or 3D. Use editable layers; those boxes come in as images automatically.

A few practical scenarios:

• "I need a PNG of this chart for a slide." Bitmap.
• "I need to redesign our pricing page." Editable layers — import it, then iterate.
• "I want to compare production with our mockup." Editable layers, with the optional Reference screenshot (Pro) — a hidden, locked image layer you can toggle on for a pixel comparison. It's a nice example of both meanings working together: a bitmap for checking, layers for working.
• "I need the logged-in dashboard in Figma." Editable layers via the Chrome extension, which captures pages your browser can see, including their current state.

Why "just screenshot it" costs more later

Screenshots feel faster because the capture takes seconds. The cost shows up afterward: someone has to rebuild every frame by hand once the real design work starts. Measuring padding from pixels, guessing font sizes, re-typing copy, recreating colors — it adds up to hours per page.

Converting to editable layers moves that work to the tool. You get measured sizes, real text, and — with Pro — variables, text styles and components generated from the page itself. The HTML to design workflow shows what that looks like across a full redesign.

Privacy note

Whichever approach you choose, think about where the page is rendered. html2canvas runs inside the page in the user's browser. HTML to Frames renders public pages in an isolated, sandboxed browser, delivers the result once, and deletes it from memory without writing it to disk; the Chrome extension runs in your own browser and sends nothing unless you use Send to Figma. Details are on the security page.

Summary

• HTML to canvas (bitmap) turns a page into pixels. Great for sharing, testing and previews; not editable.
• HTML to the Figma canvas turns a page into frames, text and vectors you can work with.
• Content that truly is a canvas — WebGL, maps, iframes, video without a poster — is captured as an image of that box, while the rest stays editable.

To see the layer-based approach on your own page, get the plugin and start with the docs, or read how the Auto Layout engine turns page structure into frames.