BuilderJS

Responsive Email Design: The Techniques That Actually Render

Responsive email design means building one email that looks right on a 320-pixel phone and a wide desktop inbox alike — without two separate versions, and without anything breaking in Outlook. It sounds like responsive web design, and it borrows the same idea, but the rules are stricter and the tooling you can rely on is narrower. Email clients are not browsers. Gmail ignores some media queries, desktop Outlook on Windows renders mail through Microsoft's Word engine and won't do flexbox or grid at all, and any client can strip the `<head>` styles your layout depends on. So "responsive" in email is less about modern CSS and more about a small set of battle-tested techniques: a fluid table-based skeleton, images that scale down inside their cell, and a media query that stacks multi-column rows on small screens — with a base layout that still holds together when that media query never runs. This guide explains those techniques in plain terms, shows where the real constraints are in 2026, and covers how a drag-and-drop builder can apply the tedious parts for you on export. BuilderJS is the editor you embed and self-host — it builds and exports the email HTML; it does not send it. Knowing that line keeps your architecture honest.

Get BuilderJS — $52 Try the builder

Why responsive email isn't responsive web design

On the web, "responsive" means flexbox, grid, container queries, and a stylesheet in the `<head>` that reflows everything fluidly. In email, most of that toolbox is unavailable or unreliable. Desktop Outlook on Windows still renders through Microsoft's Word engine, which ignores flexbox and grid and effectively requires table-based layout (as of June 2026; Microsoft has signaled an end to the Word-based desktop Outlook around October 2026 — verify on Microsoft's pages, https://learn.microsoft.com/en-us/outlook). Gmail's web client ignores media queries entirely and strips `<style>` blocks under several conditions, so any responsiveness you express only through `@media` simply won't run there (see Litmus, https://www.litmus.com/blog/understanding-gmail-and-css-part-1, and Campaign Monitor, https://www.campaignmonitor.com/css/, both as of June 2026). The practical consequence: you can't lean on media queries as your only responsiveness strategy. Instead, the dependable base must be a fluid, table-based layout that already looks acceptable at any width on its own — and the media query becomes a progressive enhancement that improves the experience where it's supported, rather than the thing the design depends on to not break.

The three techniques that do the heavy lifting

Strip away the noise and reliable responsive email comes down to three moves. First, a fluid skeleton: an outer table with a max-width (commonly 600px) centered in the viewport, so the layout fills a narrow screen and caps on a wide one. Second, fluid images: every `<img>` gets `max-width:100%; height:auto` so pictures shrink to fit their cell instead of forcing horizontal scroll — and crucially, this is set inline so it survives even when a hostile client strips all your `<head>` CSS. Third, mobile stacking: a single `@media (max-width: 600px)` rule that turns multi-column table cells into full-width blocks (`display:block; width:100%`) with `box-sizing: border-box` so cell padding doesn't blow the width back out. That's the core. Hover effects, dark-mode tweaks, and web fonts are nice-to-haves layered on top, but the fluid skeleton plus fluid images plus column stacking is what makes an email actually usable on a phone across the messy real-world client matrix.

The base layout has to survive the media query being ignored

This is the single mistake that breaks the most "responsive" emails: designing a desktop layout that only becomes mobile-usable when the media query fires — then watching it fall apart in Gmail web, which never runs that query. The discipline is to make the un-enhanced base acceptable on its own. Keep columns narrow enough, and images fluid enough, that a phone showing the desktop table (no stacking) is still readable rather than a row of squashed 50px columns. Then the stacking media query is pure upgrade: where it runs, columns go full-width and the layout feels native to mobile; where it's stripped, the fluid base still holds. The same principle applies to inline versus head CSS. Inline styles are the resilient base because they ride on the element itself and survive sanitizing; the `<style>` block (media queries, hover) is the enhancement that may or may not arrive. Build for the worst client first, enhance for the good ones second — never the reverse.

How a builder applies these techniques on export

Hand-writing fluid tables, inlining every declaration, and hand-authoring a mobile-stacking media query for each template is repetitive and easy to get wrong on the next edit. This is where an embeddable editor earns its keep. BuilderJS is a drag-and-drop builder library you mount inside your own app to design HTML email and web pages; you author in a normal modern layout, and its EmailExportPipeline transforms that into client-safe email HTML on export. Concretely, the pipeline converts flexbox/grid columns into real nested `<table>` markup (the layout Outlook's Word engine needs), gives every image inline `max-width:100%; height:auto` as a fluid-image safety net that survives even total CSS stripping, injects an `@media (max-width: 600px)` rule so multi-column tables collapse to single-column on phones (with `box-sizing: border-box`), inlines every safe `<style>` declaration onto its element while preserving the media query, rasterizes SVG icons to PNG for clients that break on SVG, and wraps the body in MSO conditional comments so Outlook locks the geometry. The library's 30+ templates and 200+ samples are Litmus-tested across 22 email clients, so the responsive output is checked against the same inboxes that cause the trouble. You design once, call `getData()` to persist the JSON, and export inlined, mobile-ready email HTML — then hand it to whatever sends your mail.

Where it ends: the builder doesn't send, and pages play by different rules

Two honesty checks worth keeping straight. First, an editor produces markup; it does not deliver it. BuilderJS builds and exports the responsive email HTML, but it does not send email, manage lists, or handle deliverability — you connect the exported HTML to your own ESP, SMTP server, or backend. The builder owns the markup; you own the send. Second, the responsive rules above are for email specifically. A landing or web page rendered in a real browser doesn't need any of the table gymnastics — it can use a normal `<head>` stylesheet, real flexbox and grid, container queries, and modern responsive CSS, and inlining there would be a step backward. BuilderJS handles this with dual output from the same design: ruthlessly inlined, table-based email HTML for the inbox, or clean modern page HTML for the browser. The trap is using one output mode for both jobs. Pick the output that matches the destination and let the export pipeline apply the right strategy. You can try the editor live at builder.emotsy.com.

Frequently asked questions

Explore