This is a simple stripped back basic template that I’d use for every email I send.
If you want to just copy and paste that code you are welcome to, just be sure to edit the content in the
If you are interested in the reasons behind why each part of the code is there, read on and I’ll break it down in more detail.
Here we’re using an HTML5 Doctype. Not every email client will respect the doctype you set, some will remove it and use their own, but that is mostly HTML5 anyway. There are small rendering differences between HTML4 and HTML5, the most common one email devs notice is, you can’t set a
display:block in HTML4.
Rémi Parmentier has written a really great article about which doctype should you use in HTML emails. If you want to know more I’d strongly recommend reading that.
<html> tag defines the document as HTML format, however if the files is saves as
.html then this is assumed anyway so it’s not really needed. However what is needed are the attributes set on in.
This sets the language of the email, it’s important to set as this can affect the way email clients, browsers, screen readers and other assistive technology interpret your content. You can use multiple languages in the same email but it’s important to only set one as the default. After that you can place a lang attribute on any element where the language changes from the default.
Here I’ve set
lang="en" to set the content in English, however you can get more granular if you like and set
en-GB for British English or
en-US for American English.
As email clients often strip the
<html> element it’s also important to set a lang on the Wrapping element.
Read more on the w3school lang attribute page, they also have a useful list of language codes.
There are a number of meta elements set here so lets look at them individually.
This sets the character encoding standard which can limit the character that are used. Unlike the lang attribute we can only set one charset for the file.
I need to set some time to look into this more but generally I believe utf-8 should cover most cases.
Be aware that the email headers may override what is set in the meta.
This tells the browser which version of IE to render with. In theory this would only apply to webmail clients opening in IE 9 or below (although meta tags are likely to be stripped from webmail), emails viewed in browser in IE 9 or below and Outlook 2000-2003 for windows.
It also enables media queries to work on some versions of windows phone.
As the years go on I think it’s getting safer and safer to remove this meta tag.
The viewport element gives the browser and email client instructions on how to control the page’s dimensions and scaling.
width=device-width sets the width of the page to follow the screen-width of the device.
initial-scale=1.0 sets the initial zoom level when the email is first loaded.
In theory these prevent email clients automatically detecting and generating links out of phone numbers, dates, addresses and email addresses. However support is low, I’ve only ever seen it work for phone numbers on the Outlook iOS app. I’d recommend including these anyway as it’s a hint to the email clients that this is something we want.
There is an argument that we shouldn’t use these as the auto linking helps users. However I feel there are too many issues with the auto detection to reply on it, if I add a phone number I will add a link myself. If I include numbers for another reason (order number etc.) I don’t want them linking to a phone number.
As the name suggests this is specific to Apple. It appears Apple were trying to fix the display of non-responsive email in their iOS email client, however when encountering a responsive email they would display at half the width of the screen and zoomed out. This meta tag prevents the Apple fix and relies on the developer to make the email responsive.
There are more details on Apple auto-scaling emails bug on the email bugs repo.
These are used to control dark mode preferences. They both do the same thing but
supported-color-schemes was renames to
color-scheme so for now we include both to get more as the old name is supported by Safari, and Mail in macOS 10.14.4.
content values are
- light - tells the email client that only light styles are provided
- light only - tells the email clients that only light mode styles are ready to use and not to try and transform them to dark.
- light dark — tells the email clients that both light and dark styles are coded and ready to use.
- light dark only — tells the email clients that light and dark styles are ready to use and not to try and transform light styles.
It’s best to set this with logic depending on if dark styles are included in the code. But if you can’t place that logic I’d opt for
The title element give a title to your document, this will be seen in the browser tab if a user selects to view the email in a browser. I have previously seen the title show in a preview for the old default Android client, it’s possible that something like that may happen again.
This code helps rendering on Windows versions of Outlook desktop.
<!--[if mso]> <![endif]-->This if statement means this code is only visible to Windows versions of Outlook desktop.
<o:AllowPNG/>This improves support for PNG images.
<o:PixelsPerInch>96</o:PixelsPerInch>This will improve rendering on machines that have a higher DPI set, this is often the case for Windows laptops that have higher than standard resolution monitors, or users who have chosen to increase the DPI.
This is essentially a duplicate of the meta color-scheme. At time of writing this only really works in Apple Mail which supports both methods but in the interest of future proofing I’m including both.
I always like to define a body class on the body element, this is because sometimes when an email renders the
<body> element is converted to a
<div>. It is also useful for targeting certain email clients.
Inside the email body we wrap the whole content of the email in this
<div>, I’ve also seen some people apply these attributes to a wrapping
<table> personally I try and avoid tables as much as possible, but if that’s your set up then you can use it on a
So taking a closer look at the attributes;
This is an accessibility enhancement, when navigating with a screen reader this will place the email into the landmarks menu and define the content as an article. Although it may not be an article as such, the definition here is something that can stand alone outside the context of the rest of the page. And email fits that description.
As I mentioned previously, article may not be the best word to describe the content, so this will rename it to email. This is a custom name so we can use anything here but I wouldn’t advise using anything else apart from maybe translating it to match the language of your content.
So we’ve said this is stand along content, we’ve said the content type is email now we give that a title. To keep it simple I’d recommend using the subject line if you can dynamically insert that or perhaps say who the email is from.
This is a duplication of the lang set on the HTML element. Email clients will often remove the
<html> element so it’s best to duplicate it here also.
Some email clients may force a font-size on your email content. This resets it to be relative to the users settings so better for accessibility. Ideally all other units in the email should be
em so they are relative to this.
Unfortunately rem units don’t work everywhere if you want to find out more look at email client support for rem units and browser support for rem units