Click to Sign Up for a 7 Day Free Trial!

Email Development

Email Development Best Practices: 2016

Email On Acid

If you're new to the world of email, you may find it a bit overwhelming. Modern web coding techniques have little to no support, and people keep telling you to use tables. Well, we're here to tell you the exact same thing. Tables are like Yoda: ancient and hard to understand but very powerful. So get used to them, you must.

What follows is a collection of the best advice we have for new email developers, stated as succinctly as possible.

Email Design

Single column design

Keep the design simple to make life easy! A single column design is sufficient for most emails (other than product based or newsletter style) and will help make it much easier to accommodate mobile devices. It's also easier for your readers to scan a single column of material than it is to jump around a lot.

Use 600px for width

We recommend that you keep your email's width close to 600px. This width should give you plenty of space and will fit nicely on most web and desktop clients. You can scale it down to fit better on mobile screens using media queries or fluid design (see below).

Keep mobile users in mind

With the rise in popularity of mobile devices, some email designers have embraced "mobile first" design. This means that they design the email with mobile primarily in mind, and then make sure it also looks good on desktop. This approach is the opposite of what many designers have been doing; designing it on desktop and then adapting it for mobile. By putting mobile users first, designers hope to increase engagement and click-throughs on mobile devices. We recommend this approach especially for simpler emails like password resets, transactional emails and account updates.

Every email client is different

When designing an email, keep in mind that it's going to be very difficult (if not impossible) to achieve "pixel perfection." Instead, try to achieve an email that maintains your branding while being easy to read (and click) on all email clients.

Plan for missing/blocked images

Some clients will block images by default, and some users will change their settings to block images so that they can save on data usage. If images aren't downloaded, it may be impossible to get your message across. To prevent this, always include descriptive alt text for your images. You can style this text in the style tag you add to the image.

Use email safe fonts

You can use Google Fonts, but you'll find that some clients don't support them and you'll need to use a special trick to get anything but Times to appear in Outlook. Here is a short list of fonts that should be supported universally: Arial, Arial Black, Comic Sans MS, Courier New, Georgia, Impact, Times New Roman, Trebuchet MS, Verdana, Σψμβολ2 (Symbol), and Webdings.

Don't forget to add an unsubscribe link!

And don't try to hide it. You don't want to be emailing people who don't want to read your emails. It's also illegal to leave an unsubscribe link out of commercial email. The unsubscribe usually appears in or below the footer. If you want to go for extra credit, set up a "manage preferences" center, which can help reduce the number of unsubscribes you see.

Email Development

Email Coding

Tables are your friend. When in doubt, table.

Forget divs and floats. Yes, I know it seems like we're forcing you to code in the dark ages of the internet, but tables are by far the most reliable way to achieve a consistent layout. They also enable us to replicate something that many email clients otherwise don't allow: floats. Okay, not really CSS floats. Tables allow us to take advantage of the align attribute, which was the progenitor of modern CSS floats.

Using align="left", we can cause tables to stack on top of each other on smaller screens. This technique is the basis of responsive and fluid design. As a basic level, it works like this: We have two tables that are each 300px wide, with align="left", inside the same container. If the screen is 600 or more pixels wide (as it would be for most desktop clients) then the tables will appear side by side. If the screen is only 400px wide, then the two tables will stack on top of each other.

Nested tables are totally safe, so feel free to nest away. You can also use colspan and rowspan, as long as you count your columns/rows carefully. Watch out for empty TDs, as some email clients don't handle these as you'd expect. Usually this issue can be fixed by adding an " " or non-breaking space character. You can control the size of this character using CSS so that it doesn't mess with your layout.

Know your framework

There are a few approaches to coding the framework of an email layout. The most popular approach has been to start with a 100% width table (to which you can apply a background color, if you want to) and then put a fixed-width table inside the container table.

For example…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="">
  <table width="100%" align="center" style="
        <table align="center" width="600" style="width:600px;Margin:0 auto;">
              Email Content Here

This approach allows you to control the color of your email, and to ensure that the content will be centered in all clients. However, it can cause your email to look quite small on mobile devices. By adding in media queries to control the size of the fixed width table, you can make the email adapt to different devices nicely.

Gmail won't allow media queries though, which is why we've seen the rise of fluid hybrid design. Fluid templates use 100% width content blocks, so that they will expand to fill any screen nicely. For more on fluid hybrid, check out our primer and our free fluid hybrid template.

Don't go over 100KB

We recommend that you try to keep the size of your email code under 100KB. Beyond this point, you'll start to see deliverability issues that prevent your email from reaching recipients. For more on how we found this limit, check out our blog on how email file size affects deliverability.

Develop with high DPI in mind

More and more devices come with high DPI (dots per inch) settings built in. You should save your future self a headache by coding in a DPI-friendly way from the start. It's actually really simple. Check out this blog on coding for high DPI to learn the three things you need to do for beautiful emails on high DPI displays.

Avoid Javascript, Flash, forms and other complex CSS/HTML

Javascript and Flash are completely unsupported in email clients, so don't use them at all. Newer code, such as HTML5 and CSS3 have limited support, but are sometimes possible (and fun!) to use. These enhancements should be used with caution. As always, test thoroughly when using any advanced code!

Test test test!

Email coding is hard! Every email client has different quirks when it comes to rendering code. Outlook for desktop (2007, 2010, 2013 and 2016) can be especially challenging. The only way to know your email will look great everywhere is to test it. Email on Acid can help you test, by generating over 60 screenshots of all the most popular email clients in less than 30 seconds.


Images are key to a good email experience. After all, we only have a few seconds to make an impression and pictures can communicate your message almost instantly. Here are a few things to keep in mind when using images in email.

Avoid entirely image based emails

If image blocking is on, your carefully crafted email won't communicate anything! If your email contains text, try to make sure it's not in an image. If it has to be contained in an image, use styled alt text to make sure your message will get across.

Add styled alt text to get your message across

If a recipient does have image blocking on, using alt text will help you get your message through. For example, an image that says "Huge Sale Tuesday!" should have that same text as alt text. You can add any styles you'd like the text to have to the inline styles of the image itself, like this:

<img src="X" alt="Huge Sale Tuesday!" style="font-size:38px;color:blue;" />

Use absolute links for images

You may be using local image references for your testing, but when you do your final send absolute image references are an absolute must!

Seeing strange padding around an image?

Use display:block and it will usually remove this extra spacing. This is actually a doctype issue.

Don't use image maps

If you need to connect one image to multiple locations, you're going to have to slice it. Put each slice in its own table cell, and then link the images. This can cause all kinds of havoc trying to get the slices to line up perfectly, so I would only do this as a last resort.

Background images take some extra work

This is because Outlook can't handle the background attribute or backgrounds set through CSS. You'll have to use VML to get backgrounds working in Outlook, and even then it can be finicky. If you're having a hard time, try using Stig's button and TD background generators so that you don't pull all your hair out.


Use inline styles

Because Gmail doesn't support most styles in the head section of an email, you'll have to inline all of your CSS before sending it out. For simplicity of development and code maintenance, we recommend that you still develop code using classes as normal. Use our CSS inliner to create an inlined version of your code before sending. You can do this from the summary page of any email test.

Avoid shorthand CSS when possible

If you see problems with a client interpreting your CSS, check to make sure you're not using a shorthand declaration. For example, "margin-top: 5px" may work where "margin: 5 0 0 0;" does not. Especially avoid three-digit hex codes. Some clients don't react well to these, so you'll want to make sure you always use the full six-digit code.

Get used to !important

If you are a web developer, you may have been trained to avoid !important at all costs. If you start coding email, though, you'll find this declaration can be invaluable. You can use it to override styles added or modified by the email client (especially web clients). You'll also get a lot of use out of !important when writing media queries, where this declaration will let you override a style with a mobile-specific one.

Get comfortable with media queries

Media queries are commonly used to create custom styles for different clients or screen sizes. The basic format of a media query for email is:

@media only screen and (max-device-width: 640px){ styles here }

This will cause the styles contained in the query to trigger only on screens of 640px or smaller. "Min-device-width" would do the opposite, triggering on screens of 640px or larger.

The most common uses of this technique are to control font sizes, image sizes, and to make some tables become 100% width so that they will fill a mobile screen. You can also use media queries to hide content that isn't necessary for mobile users. Just make sure that you use !important on styles within the media query, so that they will overwrite existing styles.

What best practices have you found?

Did we miss any excellent advice for coders new to email? Let us know in the comments below!

About the Author

Geoff Phillips

Geoff Phillips

Half writer, half email builder/fixer and half customer support, Geoff is living his dream in a role that combines his many diverse interests. Code problem or tricky client got you down? Geoff's your man.

Join the Discussion

Thank you for a thorough write-up Geoff!
I wanted to add an another important best practice - encode all special characters using Email on Acid Special Character converter or - both are good, the former uses numeric entities which are unreadable and doesn't encode all Unicode characters (like emoji). uses named entities (they're easy to read) and also it removes any invisible characters from the text (which are likely if you ever copy from Photoshop).
Email marketing is definitely a science that can't be left to amateurs and there is no other way to succeed unless such tactics are implemented. But there is an aspect of the email marketing technics that is often left out of the equation. In fact, I feel that that all the above can be almost pointless unless the marketer makes sure the website he promotes is responsive. Since, most sites are not yet responsive and using javascripts should be avoided, it is crucial to make sure that links used in the mailer/template are responsive, in order to redirect the "clicks" to the most relevant landing page.
In other terms - if you take care of all the above and make sure you have a responsive mailer (showing up nicely on a mobile device and on a desktop) but when the user clicks on the call to action and get to a desktop optimized landing page, you basically loose the visitor - or seriously decrease the chances to convert that user into a paying customer. That should be avoided at any cost as every click counts, especially in the performance marketing industry.
Laurent Malka
@Laurent I agree, that's common sense — the whole user journey should be mobile-optimised. There's no excuse, especially in 2016. However, only non-mobile-optimised website is better than both non-mobile-optimised website AND non-mobile-optimised email.
Anyway, it's a business decision and it should be proven using A/B tests. All brands without responsive websites should have periodically A/B tested this scenario.
I could not refrain from commenting. Exceptionally well written!
One important exception to the "avoid CSS shorthand" guideline is borders. In some email clients specifying "border-top-width:1px" will incorrectly draw a border around the entire element while "border-top:solid black 1px" will work as intended.

Leave a Comment