Email Template Design & HTML

At LiveIntent, we take email very seriously. What we prescribe in these guidelines stems from years of experience, research and testing.

Roughly 61% of unique email opens occur on mobile, a number that is only expected to grow. The opportunity for email in mobile is immense, making it essential to design emails for screens of any size to avoid poorly rendered emails.

These guidelines will make you an expert on key email design practices, providing you with a strict framework in which to adapt your emails for all screens.


Rules of thumb

  • Use ad formats that work in both desktop and mobile layouts, like 300x250 and Marquee
  • If you require a 728x90, scale it to fit inside your responsive layout
  • Do not hide LiveIntent ad units in your responsive layouts. This will lower the quality and price of your media by reducing viewability and decreasing CTR performance.


Pre-design settings

Before getting into the actual structure of the email, you’ll need to declare some information in the head section. Below is the standard HTML5 head section. Reuse this in your templates for maximum compatibility:

<!DOCTYPE html>
<meta charset=“UTF-8”>
<meta name=”viewport” content=”width=device-width, initialscale=1.0”>

Meta Tags

The first tag declares content type and character set. This ensures that your text and special characters are rendered properly. Make sure the character encoding used in your copy is compatible with this character set or you will wind up with funky characters in some clients. When moving your code between an html editor and your ESP (and especially vice-versa), make sure to first paste it into a plain text document, copy it again, then paste it into its destination. This will safeguard against picking up encoding outside of the character set you’ll be using.

The second tag assigns the viewport to the opener’s screen or window size and assures that the email sizes according to this value.

These assignments produce optimal viewing on a smaller screen, and are necessary to making your content responsive (more on this later).



The preheader is a snippet of text (usually 70 or fewer characters) that accompanies a subject line in a recipient’s inbox. Think of your subject line and preheader as a title and subtitle. The easiest way to insert a preheader is to place text at the beginning of your body section. The preview pane will pick up whatever text or links are nearest the opening of the section so make sure the preheader is right at the top. Otherwise your preview pane will pick up alt text from your header image or address to your links - these can create a poor reader experience.

<span>Check out this email! </span>

Depending on message or style of your preheader, you can hide or display it in the email itself.

In some cases, designers will make this text in-line with a link to their online version. This method is straightforward, as the preheader and additional text will be formatted the same way.

If you’d like to hide the preheader within the email, you can apply the display:none attribute to it. Defining a text size of 1px and matching the font to the background color will further guarantee it remains hidden:

span[class=“preheader”] {
display: none !important; }
<span class=“preheader”>Check out this email! </span>


The most effective email marketing messages are simple and easy to digest. Your design should follow suit. A single column design is the cleanest approach to email, reducing clutter and producing the fluidity to adapt your design to different screens.

A single column layout with a maximum width of 600- 650 pixels will render well on all devices and lends nicely to responsive design elements like font-size and table width. This is the cleanest and most reliable way to design for all devices at once.



The most fundamental aspect of designing email is an emphasis on nested tables. This technique may seem ancient to web designers, but is a stalwart necessity in email.

Container Table and Background

Set up a container table with 100% width and place a cell within it, also with 100% width. Setting a bgcolor here will set a background color for your email. Choose a color that nicely contrasts with the background color of your content.

<table align=”center” border=”0” cellpadding=”0” cellspacing=”0” width=”100%” style=”border-collapse: collapse;”>
<td align=”center” bgcolor=”#aaaaaa” border=”0”>
Place your content in here

Within this cell will be your first nested table and your main content section. Use this to set the width of your content. Mobile optimized emails should be 320- 350 pixels wide, while desktop emails should be no larger than 650 pixels wide. If you are using a single format for both mobile and desktop openers, 600 pixels is standard; it looks good on a desktop and will fit the shape of a smartphone. Most smartphones will automatically zoom to fit the content to your screen.

Your content container tables should have pixel-based widths, while all nested tables should be percentage based. This will allow them to stretch and shrink along with the container tables and will work well with responsive designs.

<table align=”center” border=”0” cellpadding=”0” cellspacing=”0” width=”100%” style=”border-collapse: collapse;”>
<td align=”center” bgcolor=”#aaaaaa” border=”0”>
<table align=”center” border=”0” cellpadding=”0” cellspacing=”0” width=”600” style=”border-collapse: collapse;”>
<!-- This is your main content table -->


On all tables and cells, make sure to define dimensions by either relative (percentage) or absolute (pixel) values. Don’t expect clients to automatically render them properly otherwise. When using absolute values do not include “px”, as this will cause rendering issues in Outlook. A width of 600 pixels should be inputted:

and not:

If you have empty space in your design, you can handle it with either padding or empty cells. Using empty cells is somewhat of a divisive issue with email designers, but is reliable, and definitely preferable to spacer images.

When using empty cells, make sure to define the dimensions inline in the cell:

<td align=”left” width=”250” height=”300”> Left Column Content goes here... </td>
<td width=”100” height=”300”> </td>
<td align=”right” width=”250” height=”300”> Right Column Content goes here... </td>

Padding is especially reliable for defining uniform spacing across different sections of content. Rather than dictating padding-left, padding-right, etc, you can simply list out padding in one declaration in the order: Top, Right, Bottom Left.

This example has 30 pixels of vertical and 20 pixels of horizontal padding:

<td style=”padding: 30px 20px 30px 20px;”>

It’s important to note that you’ll always drop the “px” in html attributes, but will need to include it in styling attributes like font-size or padding.


Table Attributes

Use attributes within either the <table> and <td> tags to modify the appearance of your sections. It is best practice to assign style attributes like cellpadding and cellspacing inline in your tables, even if those values are 0, to ensure the table displays as intended in older clients. Otherwise, they may take on random values.

You should also assign border=”0” to all of your cells and tables that do not have actual borders. Borders enable you to create visual guidelines and ease debugging if you run into errors. Doing a mass replace of border=”0” with border=”1” lets you do this very quickly. Once you’re satisfied with your layout, you can switch the values back to 0.

<table align=”center” border=”0” cellpadding=”0”cellspacing=”0” width=”100%” style=”border-collapse: collapse;”>
<td align=”center” bgcolor=”#aaaaaa” border=”0”>
<table align=”center” border=”0” cellpadding=”0”cellspacing=”0” width=”600” style=”border-collapse:collapse;”>
<td align=”center” bgcolor=”#ffffff” border=”0” width=”100%”>
This is your main content table


CSS (Cascading Style Sheet) support in email is lacking, most notably in Gmail and Gmail apps. For this reason, all styling should be contained in-line, rather than in the <head> section of your email.

If you really want to style your design with the convenience of CSS, use Premailer. It is an easy solution to in-line all of your CSS, but be forewarned: it exposes your code to the risks of automated modification.

It will always be safer to manually style each element individually. If you apply your styles before filling in content, it won’t be so time-consuming to copy and paste repeated styles.

<td style=”font-family:Helvetica,sans- serif; font-size:20px; text-align:left; color:#aaaaaa;”>Left Column Content goes here... </td>

The following styles are compatible with most clients, but are by no means the be-all, end-all. Feel free to get a little nuts and experiment with others:

  • padding 
  • font-family 
  • font-size 
  • font-weight 
  • text-align 
  • text-decoration
  • color

For a full list of CSS elements and client compatibility, take a look at Campaign Monitor’s comprehensive Guide to CSS in Email.


Out of the box, you’ll be limited to the handful of fonts that are compatible with all browsers, but you can always call on other languages that are either already installed on openers’ machines or imported from the web to diversify your palate.

For free, pre-hosted fonts, Google Fonts is the most reliable option. When applying a non-standard font, it’s important to always use a universal font as a fallback.


There are two ways to access additional fonts and bring them into your openers’ inboxes:

@font-face works well with Apple products: Apple Mail and iOS Mail, but not elsewhere.
@import has better compatibility, including the Apple clients, many smartphones and almost all web-clients.
To add fonts using @import, place the code pertaining to the font you chose in your <style> section:
@import url(;
Once the font is called in your <head> you can use it in your in-line styling:

<td style="font-family: NewFont, sans-serif;">

While web-fonts lack compatibility in a wide range of clients, you can easily revert back to safe fonts if an issue arises. With this failsafe in place, you can use any web-font you desire to make your font as beautiful as possible. You should make sure, however, that your primary and fallback fonts are as close as possible in height and weight, so that the fallback won’t alter your design.




Avoid using spacer images for layout. Now only are they painful to code and modify, but they can affect your deliverability, as well. Less than reputable mailers have long tried to hide unwelcome text in images, so filters are cautious of emails loaded with them. Not to mention, space images are useless when your openers have not enabled images, and most email clients disable images by default.

Instead use fixed width <td> cells and spacing to dictate how your empty space should
be laid out.


Use images in .GIF or .JPG format. Steer clear of .PNG files, as these will not display as consistently. Limit the size of your images to ensure your openers see the complete message quickly and without using a ton of bandwidth.

RIOT is a great tool for resizing and optimizing your images for the web.



Animated GIF’s will work in most modern inboxes and can make your email design striking. However, several clients, the main culprit being PC versions of Outlook, do not support animation and will instead freeze on the first frame of the gif. As long as you design your gif with both the whole animation and the first frame in mind, animation is totally safe in email.


Modifying the IMG tag

Make sure to include both heights and widths on all your images to ensure they render in the intended size. In most cases, width will suffice, but using both dimensions will ensure images display properly. Don’t assume mail clients will respect your image sizes otherwise:

<img src=”image.jpg” width=”300” height=”250”/>

Unless you are intentionally using a border on an image, assign all image borders to 0. Otherwise, Outlook 2007 and 2010 and older versions of Lotus Notes will give your images a default blue border.

<img src=”image.jpg” border=”0”/>

You should avoid using any floats or margins on your images. Instead use align and valign to place your images:

<img src=”image.jpg” align=”center valign=”middle”/>

Some clients, mainly Gmail and Outlook web clients, will randomly add spacing to your images. This will be painfully obvious when using spliced images, but should be
prevented in any case. Add the display:block property to your images to prevent unintended spacing:

<img src=”image.jpg” style=”display:block;”/>

Alt Text

Since many of your openers will not have images enabled or be opening offline, it’s necessary to provide a fallback to your image. Always use alt text to make sure openers receive your entire message in any scenario:

<img src=”image.jpg” alt=”Exciting Text!”/>

You can take this a step further to make sure your alt text is formatted in the same way as the rest of your email. Rather than using the generic alt text appearance, you can apply the following styles:


<img src=”image.jpg” width=”400” height=”300” border=”0” alt=”This is your alt text” 
style=”display:block; background-color: #0089c7; color: #fba025; font-family: Helvetica, sans-serif; font-size: 40px; font-style: italic;”/>

Font-align and vertical align have poor support, but can be applied as well. Please note that Gmail [by Google] has been known to be more likely to flag emails into the Promotion tab or Spam if there is a large presence of alt text.


Background Images

Avoid using background images. They are incompatible with most desktop clients and require a large image to be downloaded instantly for the user experience to be smooth. In addition, they’ll be useless when images are not enabled.

If you do decide to use a background image, make sure to include a background color, similar to our use of alt text and styling.

Media Queries

Responsive Design relies on media queries in the <style> section of your email. The most common method is to base your design on a desktop format and then use the @media query to serve different layouts or styles when a smaller screen size is detected. The biggest constraint with Responsive Design is that media queries are only supported by newer mobile operating systems. Gmail is the biggest offender - Google does not support media queries in any of their apps or the Gmail web client.


Supported Not Supported
  • iOS (iPhone/iPad)
  • Android 4.x native client
  • Android app
  • Windows Phone 7.5
  • BlackBerry OS 6
  • BlackBerry OS 7
  • BlackBerry Z10
  • Kindle Fire native client
  • Android Outlook Exchange via native client
  • Android app
  • Android Gmail app
  • Android Yahoo! Mail app
  • Gmail/! Mail (in browser)
  • Windows Phone 8

Width based rules

Media queries will look for the width of your device or window. Device width depends on the orientation of the device, not just it’s maximum value, so a smartphone will thus have a greater device width when held in landscape mode than in portrait. On a desktop, device width will change when you resize the window you’re viewing the email on.

The example below uses a max width of 320 pixels, applying styling to any device equal to or less than 320 pixels. This includes iPhones and many smartphones (in portrait view).

@media only screen (max-width: 320px) {*/ Styling for smartphone */ }

Min-width is used for the opposite purpose, setting a minimum screen size. This example applies styling to desktop or tablets greater than 680 pixels wide:

@media only screen (min-width: 680px) {}

Unless you only have a single rule, you should always combine both min-width and max-width in your rules This ensures that none of your rules overlap one another - in which case the one declared last in the code would be ignored.

@media only screen (max-width: 320px) {}
@media only screen (min-width: 321px) and (max-width: 649px){}


By utilizing pixel-based widths on your container tables and percentage-based widths on the nested tables within them, you’ll be able to make your entire template adapt fluidly with just a few steps.

The easiest way to make your template responsive is to change the values in your styling based on device width.

Making the width of content tables, the values of font- size, and padding responsive to
device will make your content responsive, as well.

In this example, the main content table's width and padding are resized based on device width. All tables nested within this one will respond fluidly as long as they have percentage-based widths. Additionally, the font size changes to make it more legible on a smaller screen. Make sure to declare !important on your values to ensure they are not ignored or overridden by the default values in your body section.

@media only screen (max-width: 320px) {
img[class=”desktop _ image”], td[class=”cell”] {
width: 320px !important;
padding: 20px !important;
p[class=”text”] { 
font-size: 40px !important;

When using CSS to resize the elements of your design, you can code the body of the email as a fallback. When device width matches the parameters called out in the media
query, the layout will be modified. In cases where media queries are not supported, the fallback layout will display automatically.

In addition to resizing elements, you can also use media queries to swap out entire sections. By using display:block and display:none you can display or hide content. This is most useful for re-sizing images based on device.

@media only screen (max-width 320px){ 
img[class=”desktop_image”] {
display: none;

When using this method, keep in mind that clients will download all the content in the image, regardless of whether it is shown or hidden. This means that your emails may load slower and require more bandwidth, as they’ll be downloading two (or more) times the amount of content necessary.

It's possible to use this method to show and hide entire templates or sections, but due to inconsistent support, it’s best to use a single, fluid template.

Note: LiveIntent tags should never have display:none added to them. An impression will decision whether there is an actual visual rendering or not, and hiding the LiveIntent units will have negative impacts on all performance and revenue metrics.



Due to the wide range of rendering issues in different clients, you should test your design as often as possible. Build out a skeleton layout and continually test it as you add more components, styling, and images. Test your html in chunks and make sure each element is compatible across clients before moving to the next piece. This will save you a good deal of frustration down the line.

To make sure your design is universally compatible you should test them on as many devices and web clients as you can. Set up multiple email addresses and round up all the devices you have access to.

Litmus and Email on Acid are two tremendous services that allow you to send a single email and view simulated renderings in most email clients. These apps are immensely useful and a must-have for any email marketer. That said you should still use live tests in as many environments as possible. Viewing, scrolling (or swiping), and clicking in the actual client or device will give you a better idea of your opener’s experience.

You’ll also need to send live tests in order to QA all of your links. This tedious last step is a must to make sure you don’t send out a broken message.

Also make note of specific subject lines to avoid in order prevent your emails from being flagged as spam. There are multiple articles on these across the web but Mequoda has an updated and informative one here.


Litmus and Email on Acid - Two testing platforms that allow you to see your email render in many clients at once. Similar services with extensive resources and informative blogs.
Premailer - This service will in-line all of your css for you before mailing.
RIOT (Radical Image Optimization Tool) - A free tool for optimizing images for the web and email

Have more questions? Submit a request