Responsive Email Templates


Responsive web design has grown way beyond the latest buzzword in web design. Users expect to be able to access content on any device they choose to view it from, and clients expect to be able to deliver it similarly. With an ever growing number of devices, delivering a fluid layout that reacts to the capabilities of the device is essential.

But what about email?

Email marketing is anything but dead. In fact, it seems more effective than ever. Last year “44% of email recipients made at least one purchase based on a promotional email”. Even more interesting is that “64% of decision-makers read their email via mobile devices”. If people are converting from emails and viewing those emails on their mobile devices, how do we optimize those emails for their devices and increase conversion?

Responsive email templates, or “Yo dawg, I heard you like tables”

It’s no secret that coding an email template requires tables. Lots of tables. Sadly this doesn’t change when going responsive. If anything, you’ll need more. Break the design out into rows first, then break each row out into a cell. The trick here is instead of using for each cell, use a table for each cell. Consider this simple three column layout:

Sample Three Column Layout

The markup for this would look something like:




It’s worth mentioning at this point that we’re going to use CSS media queries to alter the width of each table at the appropriate breakpoints. It’s also worth mentioning that not all email clients support media queries. So the decision needs to be made if you’re going mobile or desktop first. Not to start any flame wars, but for email templates I decided desktop first was the way to go. With support still fairly weak and not being able to use JavaScript as a fallback, it felt better to not penalize email clients that don’t support it.

The two important things to note with the example above are the inline widths being set and the classes being set. Inline elements are a tried and true way to get this to work in all email clients. We’ll be using the classes to override those widths using !important.

[prism:css] [/prism:css]

The CSS above will override our our .col3-collapse table to being the full width of our mobile layout. Because we’re using tables for each cell, each table will break onto its own line when it runs out of room. Had we used for each cell, we wouldn’t have had that ability. (Note: there is a trick where using display: inline-block; will get the cells to wrap. I had limited success with this approach across email clients.)

Also notice how the .col3-collapse class was targeted in CSS. We used an attribute selector instead of the dot syntax. This is because of a limitation Campaign Monitor found with Yahoo and classes.

Easier said than done

That’s really the big trick to getting responsive emails to work in the browsers that support them. And it sounds a whole lot easier than it is in practice. As your layouts become more intricate, you’ll be using tables in ways that feel downright blasphemous. Some good tricks to keep in mind are:

Inline Styles

While a lot of browsers support embedded styles, and we use embedded styles for our media queries, not all browsers handle the cascade like you’d expect. The most surefire way to make sure that heading looks the way you want is to put all the styles for it inline. That will mean a lot of copy and pasting, and more verbose code. Which makes the next tip all the more necessary.

Document Everything

Nesting tables starts making for some really verbose code. Commenting the opening and closing tags of the table with what content/layout goes in them makes reading the code way easier.


Different email clients handle margins and padding differently (and by differently I mean completely ignore in some cases). Anywhere you need some separation in your design, use empty elements with an inline height or width. Depending on your design and how you want things to collapse, this could make for some interesting markup. Using the example from above, let’s say we want a 15 pixel margin on either side of our teasers. This margin should be there regardless of breakpoint. We could do something like:




Here the empty cells are acting as our gutter and, with no class overriding them, won’t be affected by our media queries. The content inside the articles cell still will.

Test, Test, Test

And when you think you’re done, test it again. In different ways. Tools like Litmus are great, but not a substitution for viewing in an app or browser. And in browser comes with the added benefit of developer tools.

Pick Your Battles

Between web based clients, desktop clients, mobile apps and Outlook (yes, Outlook deserves it’s own category), there’s arguably more testing options here than with traditional responsive web design. Campaign Monitor has a good list of usage statistics for what’s being used. Keep things usable still, but don’t go for pixel perfection everywhere if you don’t have to.

Banner image courtesy of Flickr user [European Parliament](