Validate Email HTML

Why You Should Always Validate Your Emails’ HTML

2

This post was updated on June 19, 2019. It was originally published in November, 2011.

Coding errors in web pages is one thing, but errors in HTML emails is an entirely different animal to tackle. Why do email HTML errors hold so much more weight? Because an HTML or CSS error could at minimum result in a wonky experience for some email recipients or even a completely empty one for others.

Webmail Clients vs. Browsers

A large number of subscribers use webmail clients that employ more methods than just iFrames to display an email’s content. These clients include Gmail, Outlook.com, Yahoo, AOL and more.

iFrame is shorthand for inline frame, which allows a certain piece of content, such as an ad or YouTube video, to embed into the current content—in this example, an email.

Instead of sticking to just iFrames, a web browser is shared with a webmail client’s interface that does its best to ensure there’s no display conflict. That said, their interface often comes equipped with lots of embedded styles, container elements (ex: <div>) and fancy client side scripts for displaying banners or cropping out a portion your beautiful email design with the dreaded “[Message clipped] View entire message.”

Keeping valid, tidy code within your email ensures there is no conflict. Missing a closing </div> tag could result in email client formatting spilling into your email. Use an ‘unclosed tag finder’ to find and resolve any unclosed tags, such as this simple copy/paste tool from Jonathan Aquino .

Desktop Client Blunders

Along with webmail clients’ scripts or embedded styles leaking into your email, desktop clients with differing rendering engines can do some unexpected things with your HTML as well—especially in the layout.

A favourite bug of mine (yes, I have a favourite) is testing an email in Outlook and a random white square appears, or a column finishes short. This is usually the result of a missing table cell that will quickly sort itself out once addressed:

Table with missing cell

Proper Layout Order

Ensure you have everything you need in your email HTML and that they are in the right order and have all attributes and tags to make the email accessible.

Starting tags

Begin with the Doctype:

<!DOCTYPE html>

This is followed by the opening <html> tag, which contains the xmlns attribute for using Microsoft Office-specific code, as well as the language attribute so screen readers know lang=”en”:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" lang-="en">

After the <html> tag comes the opening <head> tag:

<head>

Followed by the <meta> tags:

<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<!--[if !mso]><!-- -->
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<!--<![endif]-->
<meta name="format-detection" content="telephone=no">
<meta name="x-apple-disable-message-reformating" />

Remember to also include <title></title> tag, as this is important for screen readers and will populate in browser tabs.

Embed CSS tags

Next step is to embed <style> tags if you are embedding your CSS:

<style type=”text/css”>
{styles}
</style>

Close all tags

Close the </head>,</body> and </html> tags in your HTML document:

<body> tags containing your email content and closing your HTML document:

<body>
Content
</body>
</html>

Keep the closing tags in order, because mixing these up can cause some rendering issues!

Find and Fix CSS Errors

When creating your email, you will inevitably be using CSS to style the way it looks. Whether you are embedding your CSS, linking a stylesheet or inlining the style attributes, using a CSS validator will catch any stray { or } as well as any errors.

Copy and paste your CSS into the W3 CSS validator and take note of errors to resolve.

Something to keep in mind: Gmail is a stickler for CSS validation.

If anything is wrong, it will strip the whole <style> tag. If your find that your HTML email is missing a particular style, start there. Gmail also doesn’t like peculiar formatting. When embedding your CSS styles, ensure you don’t have a space before the colon :.

No space before colon

Convert Special Characters

When creating copy for your email, it’s best practice to replace special characters (such as £ $ % < > ™®©) with the HTML character codes within the email to ensure they don’t display like this:

Question mark icon

The good news is Email on Acid has a handy character conversion feature within the Email Editor tool that will locate every special character in your HTML for fast and easy replacement.

Character converter feature gif

Play by Gmail’s Rules

Along with the strict CSS rules we laid out earlier, Gmail has some other code-specific rendering issues. The most well-known is the email HTML file size limit.

If your email HTML is close to 100kb, consider reducing it, either by removing unused CSS, deleting all empty lines and indentations or minifying code (try to find an email-specific one).

If your email HTML is over the 100kb limit, your email could be cut off mid-code or mid-sentence and your subscribers are tasked with an additional step just to absorb your message:

Gmail clipped message

A lesser known error is that when the unicode character ‘Private Use Two’, or &#146;, is included, Gmail will cut the email short there as well.

A Brief Recap

In short, the big takeaways are:

  • Always ensure your HTML and CSS is valid
  • Reformat special characters to their respective HTML entities
  • Keep your HTML file below 100kb
  • Resolve any other rendering quirks

As always, test your email when the code is finalized. Even the slightest adjustment has the potential to throw the rest out of whack on finicky email clients.

Run any other QA checks, including validating URLs and UTMs, optimizing images for proper and prompt rendering, and ensuring it’s accessible for screen readers. The easiest way to accomplish all of that is with the Email on Acid Campaign Precheck tool, where you can know exactly what is added or removed from the HTML within every check.

Don’t guess, test

Email clients are constantly changing, which is why it’s important to test your email every time; what worked yesterday might not work today. Email on Acid offers unlimited email testing on more than 70 clients and devices, so you can make sure your email looks good before it hits the inbox. Want to see for yourself? Take advantage of our free, seven-day trial.

Test Today

Author: Jay Oram

Jay Oram is part of the design and code solutions team at the email specialist agency, ActionRocket. In his role at ActionRocket, Jay is usually experimenting with new code for emails or finding that elusive rendering fix. See more articles from Jay at emaildesignreview.com or find him on Twitter at @emailjay_.

2 thoughts on “Why You Should Always Validate Your Emails’ HTML”

  1. B.Moore,

    Gmail must be converting special “space” characters to “&nbsp;”. We’ve had people submit tests in the past where I saw this happening. In pulling from those past tests, I can only deduct that they had exported from Word or that they had cut/pasted content that had special “space” characters. For example, I just ran the following:

    Table 1 (spaces created by a notepad editor)

    Table 2 (spaces I cut/pasted from prior emails which were submitted to us by our members)

      

    Table 3 (I also tried removing carriage returns here)

      

    Table 2 and 3 rendered “&nbsp;&nbsp;” inside the cells whereas 1 did not. So the moral of this story is that you are probably OK if you don’t have any characters within your empty TD.

    Thanks B!

Comments are closed.

Free Email Goodies