From Figma to Email: Why Export Does Not Work and What to Do Instead

You cannot export a Figma design into a ready email with one button: Figma produces markup with absolute positioning and modern CSS, while email clients require tables and inline styles. Below is why that is the case, and three ways to move a design into a campaign that genuinely work.

Why Figma export does not suit email

Figma was built for interfaces that open in a browser. A browser understands flexbox, grid, absolute positioning and external stylesheets. Email clients understand almost none of that list.

• absolute positioning is ignored by most email clients
• flexbox and grid are unsupported in classic Outlook
• external stylesheets are stripped; styles have to be inline
• Figma layer nesting does not map onto the table structure of an email
• design fonts are usually unavailable in email and fall back to system ones

The outcome of a straight export is predictable: correct in a browser, collapsed in the inbox. And it collapses worst exactly where corporate subscribers sit.

Method one: hand-coding from the design

The classic route. A developer opens the file, reads off sizes, colours and spacing, and builds the email on tables from scratch. It gives maximum control and the best result, but needs a specialist and time.

A pitfall designers tend to forget: a design is usually drawn for a 600- or 640-pixel desktop width, while most emails are opened on a phone. Litmus data puts Apple Mail first by opens, Gmail second — and in both cases those are predominantly mobile screens.

So an email design is worth drawing in two states from the start: how it looks on a wide screen and how the blocks restack on a narrow one. Otherwise the decisions get made for you by whoever writes the code, and not always the way you intended.

Method two: rebuilding in a block editor

Instead of writing code, the design is assembled from ready blocks: header, banner, text, button, products, footer. Each block is already compatible with email clients, so the task reduces to matching blocks to the design and setting colours and spacing.

Faster than hand-coding and requires no HTML knowledge. The limitation is obvious: the design has to be adapted to the available block set rather than reproduced pixel for pixel. In practice this is rarely a problem — emails are built from a limited set of patterns, and a good builder covers them.

Method three: layout recognition

A newer approach: the builder takes an image or a link to the design and works out the structure itself — where the header is, the banner, the button, the product cards. It then assembles the email from its own blocks, filling in the recognised text, colours and images.

This is not pixel copying but structural parsing. The output is an editable email on compatible blocks, not a picture. Accuracy depends on how closely the design resembles a normal email: conventional layouts are recognised well, experimental ones less so.

• from a design link — more accurate, because the layer structure is available
• from a screenshot — works with any image, including a competitor email
• from existing HTML — when an email is already coded and needs editing

What to check after any transfer

Whichever method you choose, run the email through a short list before sending. These are the points that most often break during transfer from a design.

• email width: 600 pixels is the safe standard
• padding applied to table cells, not to blocks
• buttons clickable across the whole shape, not just the text
• alt text filled in for every image
• total weight under 102 kilobytes, otherwise Gmail clips it
• fonts have system fallbacks

How this works in Mailvex

The builder supports all three scenarios: manual assembly from blocks, import from a Figma design link and recognition from an uploaded screenshot. The resulting email can then be recoloured against your brand kit so colours and fonts apply automatically instead of being matched by hand.

The output is an editable email on compatible blocks plus clean HTML for any email service provider.

Frequently asked questions

Can I get a pixel-perfect match with the design?

In most cases no, and that is fine. Email clients render fonts and spacing differently, so the same email always looks slightly different across inboxes. The goal of a transfer is to preserve structure, hierarchy and brand style, not to match pixel for pixel.

What should I do about the design fonts?

List them first and add system fallbacks after. Some clients will load the custom font, others will substitute — and the email has to look decent either way.

How do I handle complex multi-column layouts?

Stick to two columns and make sure they stack cleanly into one on a narrow screen. Three or more columns behave unpredictably in email, particularly in New Outlook where column stacking issues have been reported.