---

If you’re new to HTML email development, coding emails so they display consistently and perform well across different devices and clients might feel like a lot of trial and error. A fix for one client might break your email in three others, or a simple float may only function in half of the email clients. 

If you’re coming from a web development background, coding for email may seem restrictive since there are techniques used for websites that aren’t consistently supported for email, like importing fonts and CSS styles. (Find out more in our list of the biggest differences between web and email development.)

Fortunately, you can save yourself hours of hair-pulling and make your coding experience more enjoyable by following some HTML email development best practices. 

The best practices that we outline below cover the core aspects of email development: design, accessibility, coding practices, and (most importantly) testing. Because even if you’re confident in your code, it’s still important to test your emails before you hit ‘send.’ With Email on Acid, you can see what your design will look like on dozens of clients and devices.

Jump to a section in this article:

• Email design guidelines
• HTML email development
• Image handling in HTML emails
• CSS best practices for email
• HTML email accessibility
• Testing and HTML email development

Email design guidelines

It’s a good idea for email designers and developers to get on the same page from the start. Designers need to understand HTML email development practices so that they avoid requesting things or wireframing ideas that simply aren’t possible.

Use single-column design

Keeping your email design simple doesn’t just make your life easier, it also helps it look better on mobile devices. Emails with two or more columns require more testing to ensure that they’re responsive in different viewport widths and are prone to more display issues across email clients. A single-column design is sufficient for most emails, it’s easier for people to read, and you won’t run into as many unwanted rendering surprises.

Set 600px as the default width

We recommend that you keep your email’s maximum width close to 600px. This width should give you plenty of space for content 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).

Practice mobile-first design

In 2019, mobile devices became the primary way to check email for about 85% of users and accounted for 42% of all email opens. So if your email doesn’t look good on mobile, there’s a good chance the recipient won’t bother reading it.

With this in mind, it’s no wonder that many email developers have embraced mobile-first design. By putting mobile users first throughout the development process, and then making sure it also looks good on desktop, you can increase engagement and click-throughs. We especially recommend this approach for simpler emails like password resets, transactional emails, and account updates, but it also works well for marketing emails.

Mailjet Markup Language (MJML) is a simple and efficient way to develop responsive emails for mobile devices. It’s a coding language that’s worth exploring if you’re the kind of email developer who wants to expand your horizons. Find out how to get started with MJML.

Use font stacks

If you use Google Fonts or other custom web fonts, you may find that many email clients don’t support them. For this reason, it’s important to declare fallback fonts — also known as font stacks. This ensures your design still looks good regardless of the email client it’s displayed on. 

Even if your email only uses email-safe fonts, you’ll still want to use font stacks. No font is 100% supported across all clients. 

When creating a font-stack, list your fonts in order of priority — exact font, nearest email-safe alternative, then generic font. In the example below, we’ve declared that Open Sans should be displayed if supported. If not, show Arial (or Tahoma or Verdana). If none of the previously declared fonts are supported, show the client’s default sans-serif font. 

font-family: ‘Open Sans’, Arial, Tahoma, Verdana, sans-serif;

Keep in mind that not all sans-serif fonts take up the same space or display at the same sizes, so try to keep specifically-declared fonts in your stack as similar as possible. 

You’ll also want to use a font-stack compatible with Outlook. One of the many quirks of Outlook is that an unrecognized font in the stack will cause it to fall back to Times New Roman. You can address this annoying bug using one of these four fixes.

If you stick to using web-safe and email-safe fonts in a thoughtful font stack, your emails will look more consistent and you’ll reduce the amount of display issues you encounter when testing. You can still use custom web fonts, of course, just make sure you declare fallback fonts along with them. Below are some email-safe fonts you can use in your font stacks: 

• Arial
• Arial Black
• Comic Sans MS
• Courier New
• Georgia
• Impact
• Times New Roman
• Trebuchet MS
• Verdana
• Σψμβολ2 (Symbol)
• Webdings

Design for dark mode

On both desktop and mobile devices, most operating systems now include dark mode settings. Dark mode decreases the amount of light emitted from your screen by inverting the colors from dark text on a light background to light text on a dark background. This is designed to reduce eye strain, particularly at night, but dark mode can be challenging for email developers.

How does dark mode affect your HTML emails? While dark mode may invert your background and text colors, it doesn’t alter your images in any way. So if you’ve used a jpg logo with a white background, it could stand out in an unattractive way when your background switches to black. 

Optimizing logos for dark mode topped Pathwire’s survey of the biggest challenges. When designing for dark mode, make sure that logos, icons, and image-based dividers are all in transparent png format. When possible, pick colors for buttons, icons, and other design elements that will work well in both light and dark mode. 

Sometimes a design element’s color can’t be changed due to branding constraints. In these cases, add white or light strokes around dark or poorly-contrasting elements to help them stand out and be legible in dark mode. 

You can also add the media query @media (prefers-color-scheme dark) to your email to declare dark and light color schemes. This CSS query is not supported by all email clients, but it does work in Apple Mail, Thunderbird, and some versions of Outlook. 

Learn more about coding for light and dark color schemes.

Don’t forget to add an unsubscribe link!

And don’t try to hide it. You don’t want to email people who aren’t interested. It’s also illegal to leave an unsubscribe link out of a commercial email.

The unsubscribe link usually appears in or below the footer, but ideally, you should also set up a preference center. Instead of only giving readers the option to unsubscribe or stay subscribed, a preference center offers subscribers the option of selecting what type of emails they receive, or how often they receive them. Giving subscribers options can reduce your unsubscribe rate.

HTML email development

Since there’s a lot of ground to cover here, the following HTML email guidelines are broken up into three parts: HTML structure, image handling, and CSS best practices. 

HTML structure

Since HTML structure impacts virtually every aspect of your email, it’s critical to get it right. Let’s take a look at a few considerations.

Use tables when possible

Forget divs and floats. While it may seem like you’re coding in the dark ages of the internet, tables are the most reliable way to achieve a consistent layout. They also allow you to replicate something that many email clients otherwise don’t allow: floats (okay, not really CSS floats). With tables, you can take advantage of the align attribute, which was the predecessor of modern CSS floats.

When using display: inline-block, table cells will stack on top of each other on smaller screens. This technique is the basis of responsive and fluid design. It works like this: You have two tables that are each 300px wide with display:inline-block 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 table cells will stack on top of each other. Nested tables are totally safe, so feel free to nest away.

However, 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 ” ” or a non-breaking space character. You can control the size of this character using CSS, so it doesn’t mess with your layout.

Know your framework

There are two popular approaches to coding email. The most popular framework is called “responsive.” The basis of responsive emails is to start with a 100%-width table (to which you can apply styles that will affect the whole email) and then floating a fixed-width table in the center of this wrapper using align=”center”. If you use media queries, you can adapt the width to various screen sizes. Our free responsive template is a great example of this coding technique.

The other popular framework is called hybrid fluid or “spongy” design. With the hybrid technique, you set container tables to width=”100%” and constrain the container tables with a max-width style. When a hybrid design is displayed on screens wider than the max-width, the table will reach its max. On a smaller screen, the table will naturally fill the available space.

The “hybrid” part of this technique is that you must surround each table with a conditional table visible only to Outlook. The hybrid table has a fixed width, which solves the main problem with fluid design: Outlook ignores max-width statements.

The main advantage of the hybrid or fluid technique is that it works pretty much everywhere, regardless of whether the client supports embedded styles or media queries. For more on hybrid fluid design, check out our primer. We also have a few free hybrid fluid templates.

Include comments for templates and strip them before sending your emails

Including comments in your code will make editing templates easier. Because HTML email development is full of hacks and fixes for client quirks, it can be helpful to note why you added a particular style or element, especially if multiple email developers are working with the same templates.

However, when you’re getting ready to send your emails, strip the comments to help reduce file size. A great tool for prepping your code before sending your emails is Parcel. Parcel inlines, minifies, and strips comments from your code before you commit. Best of all, unlike other code editors, Parcel is designed specifically for email.

Keep email file size under 100kb

There are a couple of good reasons to keep your email under 100kb. First, it will pass through more spam filters. Keeping your email under 102kb will also prevent Gmail from “clipping” your email.

To keep your email under the limit, consider removing redundant or unused styles, moving some of the content of the email to a landing page, or removing any unnecessary characters from your code. Just make sure to test any changes before the final send!

Encode special characters

If your email service provider (ESP) uses a different kind of encoding from the kind you selected for your email, it may cause your special characters (like ©) to appear incorrectly, often as a black square or a diamond. This can affect quotation marks and apostrophes, as well. To avoid this problem, use a character encoder, or take advantage of the one that’s included with Email on Acid’s Email Editor.

Code for high DPI displays

High DPI displays can often cause issues when scaling email designs. This is because it will scale certain parts of the email (height, width, font-size etc. that are coded in px), but not other parts. To make sure your whole email scales properly, follow the steps in our coding for DPI scaling in Outlook blog post.

Include preheader text

In most inboxes, preheader text displays after the email subject line. This text is easy to code and can make a huge difference in open rates. Just make sure you don’t hard-code “default” preheader text into your template.

If you include hard-coded preheader text (usually in a field that can be modified), you may forget to customize it and you’ll send out an email with preheader text like, “PREHEADER TEXT HERE.” What a faux pas!

Instead, just include the “default” preheader text as an HTML comment. This way, other marketers and developers you work with will know why that code exists, but recipients won’t see it if you forget to customize it.

Avoid Javascript, forms, and other complex CSS/HTML

Javascript is completely unsupported in email clients so don’t use it at all. Forms in emails are insecure and email clients can flag them as suspicious or malicious content, which is not a great experience for your subscribers. If you want to use Javascript and other interactive elements in your emails, consider using Accelerated Mobile Pages (AMP) for email, but keep in mind that it has limited support. Currently, only Gmail, Yahoo!, and Mail.ru support AMP components in email. 

While HTML5 and CSS3 have limited support, they’re sometimes possible (and fun!) to use. These enhancements should be used with caution, however. As always, test every email thoroughly when using any advanced code.

Use cellpadding for spacing

Cellpadding provides reliable spacing across all email clients. If you need spacing only on one side of an image or container, you may want to use another spacing technique. Check out our blog post on spacing techniques in email for more info.

Image handling in HTML emails

The right graphics enhance the inbox experience while increasing conversions and boosting your brand. Here are some HTML email development best practices to help you optimize images.

Make email images retina-ready

Many devices include retina displays. This means that the devices have more physical pixels than their CSS dimensions would otherwise indicate. For example, a 10px-wide image might use 20 or more pixels to display. By using extra-large images, you can make sure the images appear extra crisp on these displays. For more on this technique, read our article about retina images in email and fluid retina images for email.

But, it’s also important to watch your file size so images load quickly for all subscribers.

Use absolute addresses for images

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

Get rid of strange spacing around an image

This is a doctype issue. Use “display:block;” and it will remove this extra spacing.

Take some extra time with background images

Outlook can’t handle the background attribute or backgrounds set through CSS, so you’ll have to use VML to get backgrounds working in Outlook. Even with this workaround, Outlook can still be finicky. If you’re having a hard time, try using Stig’s button and background generators.

CSS best practices for email development

Use inline styles

While some email clients, like Gmail and Outlook, have added support for embedded styles in certain applications, many other clients still require inline styles. 

To do this, you can code with classes and IDs and then make use of a CSS inliner. Email on Acid has an inliner that you can use from any email test, or from within the Email Editor.

Avoid shorthand CSS when possible

If you see problems with an email client rendering your CSS, check to make sure you’re not using a shorthand declaration. For example, “margin-top: 5px” may work where “margin: 5px 0 0 0;” does not. It’s important to also avoid three-digit hex codes. Some clients will not recognize these, so always use the full six-digit hex code.

Get used to !important

If you’re a web developer, you may have been trained to avoid !important at all costs. With HTML email development, though, you’ll find this declaration can be invaluable. You can use it to override styles that the email client adds or modifies (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 default 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.

Media queries are most often used to control font sizes, image sizes, and to make some tables become 100% width so that they’ll 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. Check out this article for more HTML email guidelines for media queries.

Note: Media queries won’t work in the Gmail app when a subscriber is using a non-Gmail account. 

And, while media queries are supported for the Outlook app on iOS and Android, there appears to be a persistent issue with certain media queries involving table cells not being recognized. If you’re having trouble getting your table cells to stack in mobile display, the quick fix is to change your <td> tags to <th> tags.

Read more about this issue.

HTML email accessibility

There are millions of people around the world with auditory, cognitive, neurological, physical, speech, or visual impairments. Designing and coding your emails so that every single subscriber can engage with them is an important part of HTML email development best practices. By creating accessible emails, you’ll improve usability for all your readers, reach a broader audience, increase engagement and retention, and minimize your legal risk.

The current standards for accessible online design are the Web Content Accessibility Guidelines (WCAG). The list of WCAG guidelines is quite extensive, but there are a few basic principles to keep in mind when designing emails:

Avoid image-only emails 

If one of your subscribers is using a screen reader to access emails, the only way they have to understand the content of your images is through alt text. That’s exactly why descriptive alt text is so important — a screen reader vocalizes it each time an image appears.

But that also means that image-only emails are completely inaccessible to anyone using a screen reader. Your image-only email might look great to some subscribers, but it’s impossible to effectively communicate all of the words it contains within one alt text. 

In addition to accessibility issues, image-based emails are also very hard on your recipients’ data plans and can be more frequently flagged as spam. Avoid these at all costs.

Don’t use image maps

Image maps can cause all kinds of havoc, trying to get slices to line up perfectly across all email clients — plus, they’re terrible for accessibility. Imagine using a screen reader and having several CTAs broken up across a bunch of tables. No thanks. 

Image maps also have issues in terms of creating larger file sizes and images being blocked in email clients. Make it easier on yourself and your subscribers by avoiding image maps when possible. 

Use high color contrast

For maximum readability try to use high color contrast in emails that conforms to the WCAG standards. If you test your emails using Email on Acid, our Email Accessibility checks will automatically flag any issues. 

Keep in mind that it’s not just the contrast between your email’s body copy and the background that you need to be concerned with. You also need to consider the contrast between link color and body copy and the readability of text overlaid on background images. Below are some tips to make sure your emails have sufficient color contrast:

1. Use text and background colors that are high-contrast. You don’t have to use stark black on white or white on black, but make sure your text and background colors contrast enough to at least get an AA rating. If you need to use a lower contrast color in your email, reserve that for headings. Often an increased font size and weight can make up for lower color contrast. 
2. Button colors. Keep your buttons simple by limiting color changes during different activity states. Instead, opt for using changes in font and button size to indicate activity. 
3. Link colors. Check that your link colors meet contrast guidelines in all activity states. Not only should they contrast against the background, but also against the surrounding text. If your link colors don’t meet accessibility guidelines and can’t be changed due to branding guidelines, you can accentuate your links by using underlined, highlighted, bolded, or italicized text.
4. Graphics and imagery. If you’re placing text on a background image, make sure it’s on top of an area of the image with the least background noise, or use a color overlay on the image that contrasts with your text. Remember that some email clients will block images, so always provide descriptive alt text.

Include icons

Using icons and other graphical indicators like arrows, stars, checkmarks, other glyphs, and emojis can convey meaning for those with visual impairments. Choose glyphs and other font-based icons instead of using image-based icons when possible. If you must use image-based icons, remember to include alt text.

Use semantic HTML

Semantic HTML adds contextual meaning when your goal is coding accessible emails. Both people and software can easily understand semantic code. The most recognizable semantic HTML is probably heading tags (<h1>, <h2>, <h3>, etc.), but others include:

• <article>
• <aside>
• <details>
• <em>
• <figcaption>
• <figure>
• <footer>
• <header>
• <lang>
• <main>
• <mark>
• <nav>
• <section>
• <strong>
• <summary>
• <time>

If you’ve worked with HTML for a while, you’re probably familiar with at least some of these tags — especially <em> and <strong>, which have largely replaced <i> and <b> for emphasizing and bolding text. But if you’re still using some older or less accessible tags, you’ll want to update your coding practice to use more semantic HTML.

Some screen readers don’t do well with certain types of HTML tags and keyboard navigation can be difficult if your code doesn’t include heading hierarchies. By using semantic HTML elements in your emails, you can ensure a better experience for users with disabilities. 

Include ARIA markup

Accessible Rich Internet Applications (ARIA) is a markup language that provides additional context regarding the layout and content of web pages and emails. The basic components of ARIA define roles, states, and properties and help individuals with disabilities better understand the UI they’re interacting with. One of the biggest steps you can take is to set table roles to rel=presentation. This helps screen readers interpret your tables in a way that makes sense to subscribers rather than reading it as confusing HTML code. 

To do this, add the following to your table:

role="presentation"

In context, this will look like this:

<table width="100%" border="0" cellpadding="0" cellspacing="0" style="min-width: 100%;" role="presentation">

Or Email on Acid’s Campaign Precheck tool will do this for you automatically.

Testing and HTML email development

Even if you’re using these HTML email development best practices, a crucial part of any email process is testing. There’s no point in spending the time making sure your emails look great on different devices if you don’t preview them on different clients and devices. 

It’s the only way to be 100% certain that your email is ready to launch.

While testing, keep in mind that it’s very difficult to achieve “pixel perfection” on every single client. Every email client has different quirks when it comes to rendering code. Outlook for desktop (2007, 2010, 2013, and 2016) can be especially challenging. 

Don’t be surprised if you can’t get your email to display exactly how you want to in every situation. Instead, try to achieve an email that maintains branding and accessibility on all email clients, and don’t sweat smaller details that don’t interfere with overall readability and usability.

When you use Email on Acid, you can test by generating live previews of your email in dozens of email devices and clients. When you test and validate the way HTML emails render, you’ll feel more confident hitting “send” and be assured that your emails display well for your entire list of subscribers, no matter what device or client they use.

This article was updated in November 2021. It was previously updated in May 2018 and first published in January 2017.