Remember those creative and interactive emails you get in your inbox? Have you ever wondered what those emails are called and how they are developed?
Those are HTML emails and a lot goes into creating those emails.
If you want to learn the ins and out of HTML emails, this is the guide for you. Here we will talk about coding and designing HTML emails along with best practices you should follow.
HTML emails are the subset of Hypertext Markup Language, which is used to create websites. Using HTML, you can add formatting and semantic markup in the emails.
In addition, HTML emails are often created using Cascading style sheets (CSS), which reflects how the email elements will be displayed. Thus, HTML provides the structure or outline of your email, while CSS adds life to it by displaying colors, images, etc.
Before we talk about how to code HTML emails, let's understand the role of CSS.
CSS, or Cascading style sheets, acts as a design blueprint in your HTML code. It describes how HTML elements, such as the color, headers, tables, images, etc., will line up and display in the email.
There are three ways you can add CSS in HTML. They are as follows:
An external style sheet is a separate CSS file that you can access by creating a link within the head section of your HTML. An external stylesheet may look like this:
<link rel="stylesheet" type="text/css" href="style.css"> </head>
In the code above, "
style.css "is a plain text file that is separated from your HTML code. The style is the name of the file and can be different for different users.
Most email clients don't support external stylesheets. Hence, it is a best practice not to use them.
As the name suggests, these sheets are embedded in the HTML using the "
<style> "element. The support for this sheet is also minimal across email clients.
For example, as per Litmus data, email clients such as Mail.ru, Android 5.1, Android 6.0, Gmail App IMAP (Android), Windows 10 Mail don't display these sheets in HTML emails.
Inline-styles are generally the safest way to ensure rendering compatibility across various email clients, programs, and devices.
With inline styles, code is applied directly to HTML elements in each line of the HTML. A CSS inline sheet may look like this:
<span style="font-size: 24px; font-family: Arial, sans-serif; color: #222222;" >Hello!</span>
This is the part where you begin coding your HTML emails. So, let's get started.
A doctype is known as a document type declaration (DTD). In an HTML email, these declarations tell an email client what version of HTML you are using so that it can properly render your email to the viewer.
Choosing a doctype is the foremost step in HTML email coding, as, without it, there is no guarantee that email clients will display your email the way you intended.
Now, you need to decide which doctype to use for emails as there are many of them such as HTML5, HTML4.01 strict, HTML 4.01 Transitional, etc.
HTML5 is the most recent and was designed to hold multiple code forms, but as it is still evolving, the support for HTML5 is limited across email clients. For that reason, you should avoid using HTML5.
Scalero recommends XHTML 1.0 Transitional and HTML 4.01 Transitional doctype declarations:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
You can choose the correct doctype for your emails from the recommended list of doctype by W3C.
After picking a doctype, you need to add the support for Vector Markup Language (VML). It is useful for ensuring that unsupported features, like background images and rounded borders, display correctly on email clients like Outlook 2007-16 and Outlook express. The code looks like this:
Dots per inch or DPI, is a measure for screen resolutions. DP scaling can also be a pain with Outlook email clients, so we suggest adding the following code inside the
<!--[if gte mso 9]>
It’s time to create theelement. Head elements contain the information that your subscribers can't see but is necessary for machine processing by email clients. The information is put under meta tags within a tag.
<meta> HTML element represents metadata that cannot be represented by other HTML meta-related elements, like
There are many meta tags you can add in HTML, but the following are the most useful in maintaining control over how basic aspects of your email display:
<meta name="format-detection" content="date=no">
<meta name="format-detection" content="telephone=no">
These meta tags will tell iOS devices not to turn addresses or phone numbers in their emails into links. You might want these elements to display as clickable links, but Apple's default blue may not go with your email color scheme.
So, these meta tags will prevent such happenings and allow you to modify your links as per your preference.
<meta content="width=device-width, initial-scale=1" name="viewport" />
This tag guides email clients on how to scale the email, precisely its width. This will help maintain the position of email content to avoid any blank space next to images or text that doesn't wrap properly.
After meta tags, add a CSS style tag to indicate that the content in your email is, in fact, CSS:
Now, you can create the overall structure of your emails. Within the email body, add a
padding:0px; margin:0px to the body tag to remove extra space in the email.
Add "`role= "presentation" ``` attribute to each of your tables to help email clients know that the table is only for visual purposes, not as a data table.
In the main table, create rows (tr) and columns (td). Within each column, create a table with a width of 600px. You can then define the content in the table.
While creating an HTML email, the design matters as much as its coding. A compelling and engaging email design can offer a better user experience. While designing an HTML email, you should consider many elements such as buttons, typography, layout, multimedia elements, etc.
Each of these elements can significantly impact how your email looks and is understood by the reader. So, paying attention to them is crucial.
To know about HTML email design in detail, you can read our complete guide on HTML email design.
When you are creating HTML emails, you must ensure email accessibility. It means every user should be able to access and read your emails regardless of their state. These states can be either human disabilities or technical, such as limited email client support.
For instance, colorblind people might not perceive specific colors in your emails. On the technical side, Outlook (web) doesn't support AMP for emails, but the Gmail Android app does.
To know in detail, you can read our guide on email accessibility.
Coding HTML emails may seem complex and confusing since there are many possibilities for email rendering. To ensure that your email renders well, you can follow these best practices:
These technologies are largely unsupported by email clients, so emails won't render properly.
Currently, only Gmail, Yahoo!, and Mail.ru support AMP components in email.
Each line of code in an HTML doc file affects the load timing of the email. This is why it's essential to keep your code organized and economical to avoid redundant lines that are just taking up space.
Also, keep your HTML file size below 102KB as Gmail will clip file size greater than 102KB. Besides, a file size of 100KB passes through more spam filters.
Avoid using mal-functional HTML tags. If there are any broken tags in your HTML code, the email client can mark it as spam or, worse, won't render it correctly. That'll hurt the deliverability of the current emails and future emails.
Avoid extra spacing around an image. Instead, use display: block, and it will remove this different spacing.
Try not to use odd numbers for sizing, such as 11px, 13px, etc., as email clients sometimes add a 1px line between email elements. Such problem is most prevalent in Outlook 2016, and your email may look like this: Source: Email on Acid
Make sure to remove any comments in your CSS in your HTML code'stag. These may ruin your code in some email clients, such as Outlook. So, it's a best practice to get rid of them if they're not necessary.
The best way to know whether your code is working or not is to test your emails. So before you send them to your final recipients, test your emails at every stage of their development.
By testing, you can spot any disparities in your HTML code. Hence, it will help you craft a consistent viewing experience for all of your subscribers.
Moreover, AMP emails are more compatible with introducing a new Multipurpose Internet Mail Extensions (MIME) part. The MIME part allows emails to fall back to HTML if a provider or email client doesn't support AMP emails.
AMP for emails is still in its nascent stages, but it is going to revolutionize email marketing. If you want to try out AMP emails, then Mailmodo is your answer. In addition, you can explore our AMP email templates and sign up for a one-month free trial.