Email design lives in a strange place. It's built in HTML, yet it's rarely designed in a design tool — the layout gets assembled in a sender, previewed in a dozen inboxes, and shipped. So when you want to rework a template, present a campaign to a client, or document your email system in Figma, you first have to get the email out of the sender and onto the canvas.
An HTML email is just HTML, so you can import it into Figma as editable layers — paste the email's HTML, or save it as an .html file and drop it in. Table-based email markup imports cleanly; watch for remote images and the fact that email fonts often fall back.
Why bring an email into Figma
The markup that renders an email and the canvas you design on are usually two separate worlds. Closing the gap is useful in a handful of recurring situations:
- Redesign a template. An old newsletter or receipt is due for a refresh, and it's far easier to rework it as layers than to edit inlined table HTML by hand.
- Present a campaign. A client or stakeholder wants to see the email as a clean artboard, with room to comment, before it goes out.
- Build a library. You're assembling a Figma library of your email components — headers, buttons, footers, product cards — from templates that already exist.
- Audit before reworking. Before touching an old template, you want to see its real structure laid out: what's a section, what's an image, where the spacing actually comes from.
Get the email's HTML first
Whatever the source — Mailchimp, Klaviyo, or a hand-coded template — the path is the same: you need the email as HTML, then you hand that HTML to Figma.
- In your email tool, open the campaign and find the HTML. Most senders offer a "view in browser" link, or an export / download HTML option; a hand-coded template you already have as a file.
- Save that page as an
.htmlfile, or copy the HTML to your clipboard. - In Figma, run the importer and either drop the
.htmlfile or paste the HTML. The email comes back as editable layers.
The mechanics of each route are covered in more depth elsewhere: turning HTML and CSS into editable layers walks through what gets captured, and importing a website into Figma lays out the paste, file, and URL options side by side.
What imports cleanly
Here's the quiet advantage of email markup: it's built for compatibility, and that same conservatism makes it import faithfully. Because emails have to render across Outlook, Gmail, Apple Mail and the rest, they're assembled from nested tables with styles inlined on each element — no external stylesheets, no clever modern layout. That's exactly the kind of explicit, self-contained markup an importer reads well.
So the structure, text, buttons and image slots come across measured from the real render — the importer reads the values the browser actually computed, rather than guessing from the source. Section widths, padding, font sizes and colours land where the email put them, because the layout was already resolved into pixels before anything was read.
The same table markup that makes email painful to hand-edit is what makes it import predictably.
What to watch for with emails
Email has a few quirks that don't show up with ordinary web pages. None are blockers, but it helps to recognise them:
- Remote images need to load. Email images usually live on a CDN and are referenced by URL — and many clients block them until you choose to load them. They have to download before they can embed as image fills, so make sure they're reachable.
- Email-safe fonts fall back. A plugin can't load a typeface that isn't installed, so an email's font is substituted for one you have. The real font name is kept, so you know what was meant to be there.
- Tables become a nested tree. All those layout tables produce a deep layer tree — frames within frames. It's faithful to how the email was built, just deeper than a typical page.
- Dark-mode variants render as shown. If the email has a dark-mode version, what comes across is whichever variant the page is displaying at the time — not both.
- Merge tags show their placeholder. Personalisation fields like a first-name token arrive as the literal placeholder text the email rendered, not as resolved data.
From import to redesign
Once the email is on the canvas as layers, it stops being a document and becomes a design again. Retype the copy, recolour the buttons, swap the hero, restructure the sections — then hand that structure back to your email build. The import is the bridge from a shipped template to a working file.
For the wider craft of reworking something existing — pulling it in, then reshaping it section by section — see redesigning a website in Figma; the same approach applies to an email template.
The bottom line
An HTML email is just HTML, which means it can come into Figma as real, editable layers rather than a flat picture. The table-based, inlined markup that makes email tedious to hand-edit is precisely what makes it import cleanly — so long as you mind the remote images and the font fallback. Bring the email onto the canvas, and you can design it again.