---

“It’s just HTML. How hard could it be?”

Those are the famous last words of many web developers who’ve been asked to code an email campaign only to discover that, when it comes to web vs. email development, there are some major differences.

If all your experience is in building websites, knowing those differences will help you appreciate what your brothers and sisters in the email world have to deal with every day. Then, if you’re ever asked to code an HTML email or two, you’ll have a good idea of what to expect.

Don’t worry, though. While HTML email development presents unique challenges that you might not anticipate — and that may require some time and effort to master — web developers are problem solvers who are up to the challenge. 

Email marketers like to say that you don’t choose the email life, it chooses you. Perhaps you have been chosen, my friend. This could be your time to rise to the challenges of email.

In this article, we’ll demystify the perplexing, and sometimes frustrating, differences between web and email development. Once you get familiar with the basics, you’ll be able to code HTML emails that look great across almost every device and email client. 

Jump to a section in this article:

1. Web browsers vs. email clients
2. Outlook: Your new worst nightmare
3. Why email developers use tables
4. Why email developers use inline CSS
5. No javascript in emails
6. Responsive design: Web vs. HTML emails
7. Coding bullet lists for emails
8. Color codes: Web vs. email development
9. Font choice limitations in email
10. Background image issues in email
11. Videos and GIF support in email

1. Web browsers vs. email clients

With web development, coding for cross-browser compatibility is standard practice. However, there’s really only a handful of major browsers you need to worry about. 

The vast majority of browsers use WebKit, Blink, Gecko, or Trident as rendering engines and, despite having some differences, are relatively standardized thanks to the Web Standards Project (WaSP). You also have a broad range of tools at your disposal to help create attractive, high-performing, and engaging websites.

Email development is significantly more limited than web development in the type of code and media you can use. It’s also complicated by the fact that, on top of having to code for browsers and devices, you need to code for various clients and mailbox providers that have very little standardization between them.

The email rendering process is also quite a bit different than web page rendering. Email clients pre-process HTML emails to prepare them for display. They remove code that looks dangerous, raises privacy concerns, or is unsupported (like Javascript). They’ll also break links to prevent images from automatically loading, and remove object and embed tags. 

When emails are finally rendered in the mail client, they’re rendered with anything from more advanced engines like Webkit, Gecko, and Trident to extremely limited engines like Microsoft Word, NotesRichText, and the soon-to-be-retired Internet Explorer. 

When you take the many combinations of browsers, devices, and email clients into account, there are literally thousands of possible rendering outcomes. It can feel a little overwhelming. 

Fortunately, the limitations of HTML email development provide a simplified, if antiquated-feeling, framework for coding. Coding HTML like it’s 2001 may feel a bit restrictive at first, but ensuring that you’re using code that has the widest possible support will help you create emails that are guaranteed to display well in just about every scenario.

2. Outlook: Your new worst nightmare

You may be looking forward to Internet Explorer’s forthcoming commitment to the dustbin of history. (Aren’t we all?) Its compatibility issues and scaled-back support from Microsoft have made it the bane of web developers’ lives for some time now. 

If you thought Internet Explorer was frustrating to deal with, rest assured that an even more sinister monster will be awaiting you in the realm of email development — Microsoft Outlook.

If you’ve taken a look at the code in an HTML email and wondered why it’s all tables, inline CSS, and outdated-looking HTML, the answer is almost always, “Because Outlook.” Unlike most other mail clients that use the same rendering engines as browsers, Microsoft Outlook has been slow to catch up. Outlook does use Webkit for Mac OS, iOS, and Android, but for Windows, it still uses Microsoft Word. Yes. Really. 

Word is not great at rendering HTML and CSS, so emails in the Windows version of Outlook can often look quite different than the developer intended. 

Here are a handful of the (many) issues you can run into when trying to render emails in various versions of Outlook:

1. 1px lines are added between elements in emails
2. GIFs only work on versions of Outlook newer than 2016
3. Margins and padding on images are ignored
4. Borders are added to table cells
5. Link styling is ignored
6. Non-native images are resized
7. HTML items’ width and height are ignored
8. All your fonts are displayed as Times New Roman, despite what your font stack declares
9. CSS background images aren’t supported
10. Your line-height is sometimes rendered incorrectly
11. Columns won’t stack in mobile

For all its flaws, Outlook is still one of the most popular email clients, especially in the B2B world. So, it’s imperative that you take its display quirks into account when coding for email. 

Learn how to work around these Outlook email problems and other Outlook display issues.

3. Why email developers use tables

Despite the fact that many email clients now have better support for CSS, that support is not consistent from client to client (especially the infamous Outlook). 

While you can use CSS positioning and sizing declarations to create your layouts, you still won’t get a consistent display even among the clients that support it. So if you want to play it safe, using tables is the best way to make sure your designs display consistently. 

But even within the seemingly simple world of tables, you’ll find a good deal of display discrepancies across different email applications. Most email clients will add their own styles to your tables, so you’ll need to declare your own attributes to ensure that the client’s default behavior is overridden. Declaring things like cellspacing, cellpadding, width, and alignment attributes will help your tables to display more consistently.

Increasingly, email developers code emails so that they can take advantage of the CSS support that some email clients offer while also using conditional comments to serve HTML tables to clients like Outlook. This is called fluid hybrid design. As you get more comfortable with building emails, the hybrid approach may keep you from feeling like you’re entirely stuck in the past. 

4. Why email developers use inline CSS

Another major difference between web vs. email development is the way CSS is used when it actually is supported.

If you’re used to developing websites, then you’re probably accustomed to avoiding inline CSS whenever possible. For faster page speeds and for keeping styles consistent across an entire website, referring to a style sheet is the best practice. 

In email development, it’s exactly the opposite — inlining your CSS will get you far better and more reliable results. Even though some email applications, like Gmail, allow embedded style sheets, few allow external style sheets. Because of inconsistent support, it’s still best practice to inline your CSS for email development.

5. No javascript in emails

Web developers rely on Javascript for many functions in a website, but Javascript applications are often the target of hackers. Javascript itself isn’t necessarily insecure, but bugs or poorly implemented code can open backdoors for malicious attacks. Due to the potential security risks, email clients don’t allow Javascript and will strip any they find in your code before your email arrives at its destination. 

If you’re set on using interactive elements in your email, you can use AMP for Email, which uses a subset of components from the open source AMP framework. With AMP emails, you can add things like polls or quizzes, embedded shopping carts, image carousels and more. It’s only supported on Gmail, Yahoo! Mail, and the Russian email client Mail.ru. But if a good chunk of your emails are being sent to these mailbox providers, then it might be fun to experiment with. 

There are a handful of email service providers (ESPs) that support AMP emails.

6. Responsive design: Web vs. email

Responsive design for web vs. email development is pretty similar, but there are a few key differences: 

Media query support 

Media queries are not consistently supported across all clients and devices. Some support them, some have partial or buggy support, and some (hello again, Outlook for Windows) do not support them at all.

Multi-column display issues

CSS and HTML table-based columns can produce some undesired results in certain clients. With CSS, ‘float’ and ‘align’ can produce uneven stacking due to lack of support for these declarations in some applications. With HTML tables, you need to specify breakpoints with min- and max-width in order for columns to stack correctly.

Image and link reformatting

You know how in web development, different browsers’ user agent stylesheets can sometimes result in unexpected display issues? Well, some mobile email clients have similar challenges with reformatting your emails with their own styles. They might change your image size or alignment, underline your links, or make all your links blue (which is not super great for maintaining brand consistency).

Using one-column design can help avoid many responsive design issues you may otherwise run into with multi-column email layout or media queries. If you feel like your email needs more than one column, Email on Acid has some responsive email templates you can try and Envato has a good tutorial on how to code responsive emails without using media queries. 

If you need a little help creating responsive emails or would just like the process to go a bit faster, you might look into learning Mailjet Markup Language (MJML). MJML is an open source framework that simplifies responsive HTML and generates it automatically.

7. Coding bullet lists for HTML emails

Bulleted lists are supported across all email clients, so these should be super simple, right? Nope. You must use <ul>, <ol>, and <li> tags for your bullets and make sure you inline your styles. Some important styles to declare include:

• Type: To prevent email clients from displaying bulleted lists in their native, default type, you’ll need to declare your list type. The following list types are supported in email:
  • Unordered lists
    • Disc •
    • Circle ○
    • Square ■
  • Ordered lists
    • Decimal numeral (1)
    • Alphabet (A, a)
    • Roman numeral (I, i)
• Margin-left: Some email clients will display bullet points outside of container boundaries (or they won’t display at all). Declaring something like ‘margin-left:20px;’ will help make sure your bullets appear within the container.
• Line-height: You’ll need to declare line-height on your lists if you don’t want it to inherit whatever the default line-height is for the mail client.
• Padding-left and margin-bottom (for nested lists): In order to give your nested list some extra horizontal spacing, you may need to declare padding-left. If you want some additional space below your nested list to separate it from the next parent list, you’ll want to add a margin-bottom declaration.

You’ll probably also want to include any special font formatting that differs from your other body text, such as font-family, font-style, font-size, font-decoration, color, etc. If you want your bullet points to be a different color or size than your text, use a <span> tag to style them.

Check out lists.cm for a handy tool that helps you build bulletproof bullet lists in emails.

8. Color codes: Web vs. email development

In web development, you have the luxury of being able to use 3-digit or 6-digit hex codes as well as RGB and RGBA values. In email, 6-digit hex codes are the only ones that are universally supported. 

For email clients that have CSS support for ‘background’ and ‘background-color’ properties, you can use 3-digit and 6-digit hex codes as well as RGB values pretty consistently. RGBA has less consistent support. 

But if you’re using the HTML ‘bgcolor’ property, then you’ll run into a lot more limited support for anything other than 6-digit hex color codes. Once again, our good pal Outlook does not support other ‘bgcolor’ values besides a 6-digit hex. Yahoo! Mail, Web.de, AOL Mail in Microsoft Edge, and Windows 10 Mail don’t support any other values either.

Because of this limited support, it’s probably best to stick to 6-digit hex codes.

9. Font choice limitations in email

If you’re coming from a web development background, you should be familiar with font stacks and web-safe fonts. Even though custom web fonts are supported by almost every major browser, it’s still best practice to include a series of web-safe fonts, in order of preference, to be displayed in case the custom font can’t be rendered. 

The same basic principle holds true for email development. Font stacks are crucial to getting your emails to display well across all email clients. But there are a few differences between font stacks for web development and font stacks for email. 

The list of email-safe fonts is even shorter than the list of web-safe fonts. Below are some email-safe fonts that 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

Font stacks are sometimes not honored in Outlook. In some versions of Outlook, if a font is encountered that is not supported, Outlook will ignore everything else in the font stack and just display Times New Roman. So you’ll need to implement some workarounds to get your font stacks to display correctly in Outlook.

Learn more about the best fonts for email.

10. Background image issues in email

When coding for websites, your biggest concern with background images is probably delivering oversized images, incorrect file types, or broken image source links. With email, background image handling is a bit more complicated.

For one, images of any type might be blocked by some email clients by default. Also, background images aren’t supported across all clients and some, like Outlook and Windows 10 Mail, require special vector markup language (VML) in order to display background images correctly. 

Other email applications just have some finicky quirks. For instance, Windows 10 Mail requires that width and height sizes for background images be in pt vs. px format. Yahoo! Mail and AOL Mail don’t always respect ‘background-image:cover;’. And there’s inconsistent support for CSS declarations that control background image behavior.

That’s why, if you have a background image in your email, you should always declare a fallback background color that maintains good contrast with your foreground color. If, for some reason, your background image can’t be displayed, at least a suitable background color will be displayed so that your overlaid text, icons, or buttons are readable.

Learn more about coding background images for email.

11. Videos and GIF support in email

Yet another big difference in web vs. email development is the ability to add video content.

There are a lot of options for video and GIF support if you’re coding for the web. In email, your options are much more limited. Gmail and many other email clients don’t support embedded video. Support for GIFs is also inconsistent across different email applications. 

If you want to use video in an HTML email, keep in mind that support is very limited and you should always use a fallback image to display on clients where video embeds aren’t supported. A handy trick to get better engagement from these fallback images is to overlay a faux play button on the image, prompting subscribers to click on it.

GIF support is better than video support, but it’s still limited. Want to guess which client doesn’t consistently support GIFs? That’s right — Outlook. 

If you want to use GIFs in your emails, try to keep them under 200kb and make sure you use conditional code to target non-Outlook subscribers with GIFs and Outlook subscribers with static image alternatives.

Aren’t there any email standards?

The web development community has WaSP, so what does the HTML email development community have? Is it still the Wild West out here? 

While email clients are slowly creeping towards support for more modern coding practices, the email community is striving for the implementation of standards. You’ll find out more about that in 2022!

Despite the lagging standards, there are still some email coding best practices that are widely accepted. Plus, some resources, like Can I Email, help both new and seasoned email developers stay on top of what’s currently supported by different email clients.

With the support and collaboration of mailbox providers and influential email marketing thought leaders, things will continue to steadily improve. In the meantime, the best way to catch email client inconsistencies before you hit ‘send’ is to test, test, test.

The secret weapon: Pre-send email testing

In this article, we’ve barely scratched the surface of the complexities of coding for email. Many other little quirks and caveats for email development exist. 

Since email is always evolving, the best way to know if your emails will render correctly is to preview them across multiple browsers, email clients, and devices. Doing this manually would be impossibly time-consuming.

Fortunately, Email on Acid’s Campaign Precheck makes testing and troubleshooting emails swift and painless. Quickly test how emails will display in dozens of inbox providers and devices. Share test links with team members and clients, add comments, and make edits directly within your email previews. Best of all, we provide unlimited email testing, so you’ll never hit a threshold. Test as many times as you like until you get it right.