On this page you can find tips on how best to code for compatibility, including answers to commonly asked questions. A basic knowledge of HTML and CSS is required for working with Email Creatives, and these guidelines are written with that in mind. However, even if you don't have experience in HTML, you still may find some answers below to questions you have about why your creative is appearing a certain way. If you don't have any specific questions, reading through all of the questions can give you a good idea of how best to work with HTML for email.
Click on a question below to see its answer.
- What languages can be used when making email creatives?
- What elements and styles can I use?
- What programs can be used?
- Is there a standard HTML setup that I can use?
- How should styles be added?
- Should the structure be made using tables or divs?
- What is the best way to position text within cells?
- How should font styles be set up?
- What fonts can be used?
- How can I include animations and videos in my email?
- Are there size restrictions for email creatives?
- Can I use responsive design in an email?
- Why are gaps appearing between images when viewing my email in a web or mobile app?
- Why is my black text turning purple in Gmail?
- Why aren't my background images appearing in Outlook?
- Why does Outlook have extra space between some of my rows?
- Why are symbols in my creative not showing up correctly?
- Why is Outlook distorting or not displaying my image?
- Why are my columns shifting over in Outlook?
- Why are my rows changing order?
- Why are text and images overlapping when I rotate my phone on iOS?
A few HTML elements are outright forbidden, since they can impact deliverability and functionality. These include the following:<form>Otherwise, all elements and styles can be used, but different clients will interpret them differently, and sometimes simply not display unfamiliar elements and styles. Elements introduced in HTML5 generally have very poor support in email, and Outlook is not that great and using the same styles as other clients. This link can help give a good idea on what will and won't work as far as styles go: CSS Support Guide
An Email Creative can be made using just a plain text editor if you know what you are doing, but dedicated HTML editing programs are generally easier to use. Dreamweaver is often considered the industry standard when it comes to HTML editing, and it can be used for editing email creatives, but try to avoid using the visual editing tools for actual editing. Emails don't follow current standards when it comes to HTML, so editing the code directly is always the safest way to edit. A great free option for HTML editing is also made by Adobe, called Brackets.
If you have one large image that you want to apply multiple links to, we recommend using Adobe Fireworks. Its slicing feature is able to create compatible code in a very straightforward manner. Before using it though, you will need to change a few settings to make it work best for email. Under File, choose HTML Setup. Change 'HTML Style' to 'Generic HTML', 'Extension' to '.html' and then go to the 'Table' tab. Change 'Space with' to 'Nested tables, no spacers'. Other programs also offer slicing tools to make HTML files, but they do not create as compatible code as Fireworks does when using those settings.
If you don't have experience working with HTML, you may want us to do the work for you. We offer several different types of HTML Creative Services, which can be found by clicking on the Pricing tab at the top of the page.
We use the following shell when making creatives. It includes a few items that generally make HTML emails more compatible with various email clients, and is immediately responsive. You can copy the code for that shell from the box below.
For the most part, it is recommended that any styles necessary for the look of your email be added inline. This means adding the style declaration directly in the "style" attribute on the appropriate element, rather than including all of the CSS in the head element. There are some cases where some styles will need to go in the head element, such as responsive styles, but your email should be set up in a way wherein if the entire head element is removed, that your email still looks as desired. If you have styles already set up in your head element that you want to be made inline, you can try using this tool: Inliner.cm.
Please note that CSS should never be never be included as a separate file, all necessary styles need to be either in the head element or inlined.
While div elements can be used for certain applications in HTML email, your overall layout should be done using tables. Outlook is the main reason for this, as it cannot properly position div elements. Using tables will ensure a compatible layout, but do not use colspans or rowspans in your table. Doing so can create inconsistencies, so if different numbers of columns are needed in different rows of a table, nest another table inside the cell that needs more columns instead. Here is an example:
Positioning content within a cell should generally be done using padding styles on a cell. This is the safest way to position content, though using margin styles on paragraph elements is also an option. The only issue with using margins on paragraph elements is that this will not work in Outlook 2007 or 2010, so it may not look right for users of those programs.
Font styles should be included inline on table cells. Outlook does not carry font styles down from parent cells, so each cell containing text needs to have those styles specified. In addition, line-height should only be applied to cells, and not span or paragraph elements.
In general, you should be sticking with websafe fonts for best compatibility. Hosted fonts do not work in some email programs, and even setting up backup fonts will fail in Outlook when using hosted fonts. For best results, use one of the font families shown here.
This answer can be split up into three points: width, height and file size.
For width, you want to keep in mind users that have basic netbooks. While resolutions continue to get higher, many users are using screens with 1366 pixel wide monitors, and others are using high density screens that report a DPI different from their PPI. When you take into account that many emails are being viewed in preview panes, or in web based email clients, there is little actual area given to the email itself. Because of this, a good width for an email is around 650 pixels wide. We recommend not exceeding 750 pixels, and going below 550 becomes too cramped to work with. Note that phone displays will generally report between 320 and 450 DPI, but this does not mean you should code your email to be 320 pixels wide. Emails will be automatically resized to fit the screen on modern mail apps, and your design should be responsive anyway to account for small touch interfaces.
When it comes to height, there's no real restrictions except for with images. Outlook will distort images that exceed 1728 pixels in height, so make sure no single image is above that height.
File size is very important to consider. Your standard email should be only about 200 kilobytes in size, including images and any other assets. This small size is to account for users with slow data speeds, since most people won't wait for an email advertisement to load. It also helps with deliverability. In addition, some users could be on metered data plans, where every megabyte counts, so opening an email that eats up their data could lead to complaints.
Responsive design in email works the same as it does in standard web design (if you aren't familiar with responsive design, I'd recommend starting here). Both iOS and Android, including their Gmail apps, support media queries in CSS, so if your email is properly responsive in a browser window, then it will likely be properly responsive in an email viewed on a mobile. If you would like some practical examples of responsive design in email, you can view our templates by clicking on the link at the top of the page.
The most common cause of this problem is that the images in your creative are displaying inline. Changing the images to display block instead will usually fix the issue. If you need your images to be inline for whatever reason, a backup solution is to set the font-size of the cell containing the image to 0.
This is an issue you will only see when testing, it will not occur on a live broadcast. The reason you see it happen is because of how Gmail does conversation view. When you receive two tests for the same campaign, Gmail will see that they are related and group them into a conversation. It will then determine that text in the second copy is quoting text from the first, so it makes that quoted text purple. This will only occur if the text color is either not specified, or is specified as black (#000000). If you want to prevent this from happening altogether, don't use black as a text color. As a replacement, you can use #000001 instead, which will look identical.
Outlook does not properly support background images. One workaround for this is to use an Outlook conditional code called a 'fill' instead. The easiest way to implement these is by using Backgrounds.cm. Note that backgrounds in general can be very tricky to incorporate when involving both Outlook and mobile apps, so we tend to avoid using them on our end. You are, however; free to include them as you wish in your own creatives.
Starting in Outlook 2013 for Windows, cells that were less than 20 pixels in height would have their height increased. There are two pieces to this solution. First, make sure the cell isn't empty. If it is, include a non-breaking space in that cell ( ). Second, set the font-size of the cell to 0. This should prevent the rows from expanding.
If there are symbols in your creative that do not look right, the safest way to fix this is to use HTML entities. For example, instead of placing © in your HTML, use ©. You can see examples of HTML entities here.
The first thing to check when this happens is the height of your image. If the actual height of the image exceeds 1728 pixels, then the image itself needs to be resized to be less than 1728 pixels tall. This shouldn't just be changed using HTML, you should modify the actual image file.
If none of your images exceed 1728 pixels in height, then the next thing to check is the height and width attribute on the image. Make sure that both are set to the size that you want. Outlook will by default attempt to display images at their actual size, regardless of styles, but it will listen to attributes. So if your image is 900 by 900 pixels, but you want it to display at 600 by 600; either resize your image to the appropriate size, or add a width and height attribute specifying those desired dimensions.
The most common cause of this problem is the use of colspans in a table. Outlook does not understand colspans very well, so avoid using them. Instead nest your tables, as shown below:
This is generally the result of bad table structure. All tables must contain a row, and all rows must contain cells. If a row is closed, then the table must either be closed, or a new row must be opened. If you are not sure if your table structure is correct, try using this HTML Validator to check.
Mobile apps have a smaller display area than desktop apps. Regardless of a phone's actual resolution, its effective width will generally between 320 and 425 pixels. If your creative is responsive, then this will not be an issue. If you have only set up your creative for one width, however; the mobile app will attempt to scale your creative automatically to appropriately size it on the smaller screen. This works fine for the most part, but it can lead to problems when rotating the device. This is because the actual scaling only happens when the email is opened, and it doesn't re-scale when the phone is rotated. The best solution for this would be to make your creative properly responsive, as this will have the largest benefit for the user as well. If that isn't reasonable though, the automatic scaling can be disabled by adding the below <meta> tag to the head element of your creative.