Coding emails from scratch: a guide to the best practices

Kristina Lauren

August 15, 2021

You see them everyday as you scroll through your inboxes, and maybe you’ve even created your own using a template builder, but do you know the ins and outs of what goes into crafting a dynamic, vivid html email? And have you ever coded html emails from scratch?

Understandably, everyone is not interested in doing so, but having some idea of how an email is birthed can give you more insight into your subscribers’ POV and help you deliver better email content. However, we should probably define these emails first.

What are HTML emails?

HTML stands for HyperText Markup Language and is used to code a document, such as an email, in a way that tells an HTML reader, such as an email client, how to display information.

These are more complicated than plain-text emails, which, as their name suggests, are emails that consist of simple text without any beautification.

HTML emails tend to be a lot more aesthetically pleasing with graphics, colorful sections that stand out from each other, and a lot more flexibility as far as design goes. In basic terms, you can think of these emails as plain-text emails that have been given an extreme makeover.

Whether you have some experience with HTML and CSS or not, coding emails is something that anyone can learn with enough patience and proper guidance. Below you’ll learn the basics of setting up an HTML email, as well as a few tips and tricks to ensure your code renders perfectly.

Let’s get started

Before you can begin coding anything, you’ll need to decide on which version of HTML you want to work with so that email clients know how to display your email to your subscribers. This is called a doctype. Technically, you could leave it up to chance and not assign a doctype, but using one is highly recommended to ensure that your emails are seen the way they were intended to be seen.

So, which is the best doctype to use for email? HTML5 is the most recent doctype and was designed to hold multiple forms of code, making it ideal for cross-platform options. However, it is still evolving and isn’t supported by all email clients. That’s why we recommend these 2 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">

These transitional doctypes allow you to use particular elements and attributes that aren’t allowed in strict doctypes, such as presentational or deprecated elements, giving you a little more flexibility with your code.

VML and DPI Scaling

After picking a doctype for your email needs, you’ll want to add the support for VML code. VML stands for Vector Markup Language and it’s useful for making sure that unsupported features, like background images and rounded borders, display properly on Outlook email clients.

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">

DPI scaling can also be a pain with Outlook email clients, so we suggest adding the following code inside the <head> tag:

<!--[if gte mso 9]>
<xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml>
<![endif]-->

The Head

After adding in all the above code, it’s time to create the <head> element. The information in this section won’t be visible to any of your subscribers, but it’s necessary for machine processing by email clients. The following pieces of code will need to go in this section, specifically nested within a <head> tag.

Meta Tags

There are various meta tags you can use, but we find these 3 to be useful in helping you maintain more control over how basic aspects of your email display:

<meta content="address=no" name="format-detection" />
<meta content="telephone=no" name="format-detection" />
<meta content="width=device-width, initial-scale=1" name="viewport" />

The first two meta tags will keep iOS from turning any phone numbers or addresses in your emails into links. Of course, you may want these elements to show as clickable links, but Apple’s default blue may not match the color scheme already in your email, so including these meta tags will prevent this override while allowing you to tailor your links to your liking.

The third tag is used to give a browser guidance on how to scale your email, specifically on how to set the width. This will keep your email content positioned neatly so that you don’t get weird blank space next to your photos or text that doesn’t wrap properly.

After your meta tags, add in this CSS style tag to indicate that the content in your email is in fact CSS:

<style type="text/css">

Body and Tables

Next comes the overall structure for your email, where all your beautiful graphics and selling points will go. This section begins with a <body> tag, which goes right under the <head> tag. You can also remove any space around your email by adding padding:0px; margin:0px; to the body tag.

Within the body, insert a <table> tag for the main container and give it a width of 100%, since it will hold most of the email content.

Be sure to add role=“presentation” to each of your tables to make it clear to email clients that the table is being used visually instead of as a data table. Every table will also be implemented with border=”0″ cellpadding=”0″ cellspacing=“0”.

Once you have your main table, create a new row (tr) with one column (td). Inside this column, create a new table. This will help you to define your content (we suggest 600px wide).

Since your email will be viewed on multiple viewports, make sure the email is optimized for the different types. Desktop, for example, has a larger viewport than mobile which gives you more horizontal room for your layout. Mobile on the other hand has a much narrower scope, which means you’ll have to stack most of your sections in order for the email to be viewed properly. You can account for these contrasts by using media queries, which will allow your email to display differently when viewed on mobile devices.

It’s also good practice to use attributes such as “align” and “valign” for your tables. If you’re familiar with HTML, you know that these attributes are considered deprecated, or obsolete. However, since email clients widely vary in terms of CSS support, you should use certain deprecated elements to make sure everything displays as intended and avoid any strange-looking tables.

Below we’ve summarized all the previous steps so that you can refer back to them at any point during the process of creating your email.

Pick and enter a doctype at the top of the html document
Insert code for VML and DPI Scaling
Create a head element
Insert meta tags and first CSS Style tag into the head element
Create a body tag underneath the head element
Insert a table tag as the main container within the body tag
Add a row to the inside of the main container table
Add a new table with the preferred size for your content, adding rows, columns and nested tables to define your layout.

A shell to get started

To summarize the above steps, we’ve put together a sample shell for you to work from:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">
  <!--[if gte mso 9]>
  <xml>
  <o:OfficeDocumentSettings>
  <o:AllowPNG/>
  <o:PixelsPerInch>96</o:PixelsPerInch>
  </o:OfficeDocumentSettings>
  </xml>
  <![endif]-->
  <head>
   <meta content="address=no" name="format-detection" />
   <meta content="telephone=no" name="format-detection" />
   <meta content="width=device-width, initial-scale=1" name="viewport" />
   <style type="text/css">
    /* styles go here */
   </style>
  </head>
  <body style="padding:0; margin:0">
    <table border="0" cellpadding="0" cellspacing="0" style="margin: 0; padding: 0" width="100%">
      <tr>
        <td align="center" valign="top">
          <table width="600" style="width: 600px;" border="0" cellpadding="0" cellspacing="0">
            <tr>
              <td>
                /* content goes here */
              </td>
            </tr>
          </table>
        </td>
      </tr>
    </table>
  </body>
</html>

Some other helpful CSS hacks

Email clients have a habit of positioning and displaying things in ways that don’t always align with the vision you have in mind for your design. That’s why the following CSS coding tips are helpful in limiting the annoying, disruptive formatting these email clients like to implement after you’ve created your email.

To get rid of any unnecessary or awkward spaces around the body content of your email

html,
body {
margin: 0 auto !important;
padding: 0 !important;
height: 100% !important;
width: 100% !important;

The !important rule essentially overrides all styling that was used previously for that element. In this case, it will stop email clients from adding any automatic padding or margin to your email while keeping your height and width consistently at 100% of the viewport. The code above can also remove padding and margin as well as add a background color to your reply window, which may not match your color scheme, so be mindful when using it.

To properly add in fonts

Choose the right font stack–below we’ve included the one for Helvetica. However, if you’re going to use a custom font that you want to load from your local server, use the font-face at-rule.

For Outlook, you can then add the fallback font inside the <head> tag.

<!--[if (gte mso 9)|(IE)]>
<style type="text/css">
table, td, a, span, p, ul, li { font-family: Helvetica, arial, sans-serif !important; }
</style>
<![endif]-->

To preview your text, add the following code inside the body tag

The repetition of “‌&zwnj; ” will fill any leftover preview text space so that email clients don’t show extra text or characters in the preheader.

<div style="display: none; max-height: 0px; overflow: hidden;">
YOUR PREVIEW TEXT
</div>

<!-- Insert &zwnj;&nbsp; hack after hidden preview text -->
<div style="display: none; max-height: 0px; overflow: hidden;">

To stop email clients from resizing small text

* {
*-ms-text-size-adjust*: 100%;
*-webkit-text-size-adjust*: 100%;
}

To prevent Outlook from adding extra spacing to tables

table,
td {
*mso-table-lspace*: 0pt !important;
*mso-table-rspace*: 0pt !important;
}

To fix webkit padding issues

table {
*border*: 0;
*border-spacing*: 0;
*border-collapse*: collapse;
}

To make Samsung Android mail clients use the entire viewport

#MessageViewBody,
#MessageWebViewDiv {
*width*: 100% !important;
}

To improve rendering when resizing images in Internet Explorer

img {
*-ms-interpolation-mode*: bicubic;
}

To prevent Windows 10 Mail from underlining links despite inline CSS

a {
*text-decoration*: none;
}

To block email clients from automatically linking certain text strings

For iOS

a[x-apple-data-detectors],
.unstyle-auto-detected-links a,
.aBn {
*border-bottom*: 0 !important;
*cursor*: default !important;
*color*: inherit !important;
*text-decoration*: none !important;
*font-size*: inherit !important;
*font-family*: inherit !important;
*font-weight*: inherit !important;
*line-height*: inherit !important;
}
u+#body a,

For Gmail

#MessageViewBody a

For Samsung Mail

{
*color*: inherit;
*text-decoration*: none;
*font-size*: inherit;
*font-family*: inherit;
*font-weight*: inherit;
*line-height*: inherit;
}
</style>

Some General Reminders

When using links to code html emails, be sure to use the full address to stop unexpected text from showing up on certain email clients. For example, instead of using www.scalero.io, you should use https://app.scalero.io.
Avoid odd numbers when it comes to sizing—11px, 13px, etc. as these can cause abrupt lines to appear in your emails.
Remove any comments in your CSS in the <head> tag of your code–these can trip up email clients so if they’re not necessary, it’s best to get rid of them.
Create an effective naming convention to keep your code organized. This will prevent confusion for both you and anyone else who looks at the code later.
All CSS styling for your content, such as font-family or text-align properties, should be inline. This is because not all email clients support CSS selectors, like classes and ids, which can leave your email missing the key elements that are meant to make it an attractive design.

Final Tips

Don’t Rely Too Heavily on Pictures

Most of your subscribers will likely enjoy seeing colorful, vibrant pictures when they open your emails, but you shouldn’t primarily count on images to get your point across. Some of your recipients may not have auto image-loading activated or your email may not fully load on their servers, which means that when viewers open your emails, they’ll only see blank squares. These scenarios are totally out of your hands, but what you do have control over is the ability to add alt-text. This descriptive text will load even if your images don’t and give your viewers an idea of what they were meant to see.

Email Safe Fonts

While it may be enticing to use a custom font, this can add an unnecessary level of complexity to your emails. Even with all of the coding precautions we’ve gone over, your email is still at the mercy of whichever clients your subscribers use, which is why it’s best to use email safe fonts. It also doesn’t hurt to check to see which email clients are most popular with your subscribers so that you can determine if a certain font will work for the majority. In one of our recent articles, we delve into what email safe fonts are and how you can pick the perfect one for your needs.

Get Rid of the Junk Code

Each line of code in an HTML file affects the amount of time an email will take to load. This is why it’s important to keep your code organized and economical so that you can do away with any redundant lines that are just taking up space. Having code that is too long can also result in your emails getting clipped. This isn’t the end of the world since your subscribers will have the option to click to view the entire email, but you don’t want to put your subscribers through the hassle of having to wait for your email to load in another window. To prevent this, try to keep your file size below 100kb.

Test, Test, and Test Again

It’s imperative to test your email at every stage of its development. Not only will this make the debugging process easier, but testing as you go will help you spot disparities between multiple email clients and aid you in crafting a uniform viewing experience for all of your subscribers. Check to see if your HTML editor has the option to let you view changes as you work or preview your email before publishing it so that you can get a decent idea of how the email will look on different devices and in various email clients. We also always suggest using a tool such as Email on Acid to ensure the email is rendering well across devices.

This may all sound a little overwhelming, especially if you’re completely new to the world of HTML and email creation, but as you become more familiar with the coding process and figure out what is most vital for your particular email campaign, these practices will become like second nature. While you’re learning, our team of skilled email designers and developers can both advise you on the best email creation strategies, as well as build emails from scratch to suit your needs.

If you’d like to see a ready-made template built by our team to work from, we are happy to provide it for you. Just sign up for access to the Scalero app for more info!