Emails don’t need to look the same in every email client, but there are some best practices and guidelines to keep in mind to make sure they are consistently designed, render properly in email clients, and are as accessible as possible.
Given Stack Overflow’s reach, we strive to support email clients with low levels of HTML & CSS support (namely Microsoft Outlook, a few versions of Gmail , and a handful of mostly non-US clients ). Less than 1% of a mailing list can still mean a few thousand users, so it’s safest to code emails like it’s 1999.
- CSS2 instead of CSS3
- Tables instead of Divs
- Inline CSS instead of embedded styles or stylesheets
- HTML text instead of images containing text
<table border="0" cellpadding="0" cellspacing="0" role="presentation">
This negates any unwanted spacing and borders and tells screen readers to skip over the table’s tags and move straight into the content.
For finer control of your HTML, try nesting tables when building emails.
Margins aren’t fully supported on tables and container elements.
Margins are fully supported for headline, paragraph, and list tags.
Most styling is done via CSS. But because some email clients use antiquated rendering engines, they tend to better understand attributes like align
, valign
, height
, and width
.
align
float
grid
flexbox
Floats aren’t supported in Outlook and the others don’t have good support in general.
#ffffff
#fff
rgb(1,2,3)
Six-digit hex is supported in inline CSS as well as HTML attributes like bgcolor
that are still supported in email.
We can specify the text that appears beneath subject lines in many email clients. If preview text is not included, this space will be populated by the email’s content.
SVG has almost no support in email, no matter how it’s referenced (inline, Base64, .svg
).
Since SVG isn’t supported, a 20x20 raster image coded like <img src="40x40-image.png" height="20" width="20">
displays crisply on high-definition screens.
role="presentation"
.This prevents screen readers from reading aloud the structure of each table cell.
Tags like <p>
and <h>
allow screen readers to quickly jump from section to section. Tags like <strong>
and <em>
give text more importance.
alt
Be descriptive and use alt
to help readers “see” the email if images aren’t displayed. Use an empty alt=""
for images a screen reader should skip (eg. decorative images). Screenreaders will dictate the filename of images without an alt
attribute (eg. "icon dash checkmark dot png").
It helps us avoid spam filters, some email clients don’t support HTML, and some people just prefer plain text. They also respond better to things like changing font size, family, and color, and work well with screen magnifiers. We don’t have many rules or guidelines for formatting plain text emails, though they typically look something like this . Our email service providers have tools to convert HTML email to plain text.
Tools to ensure emails look as they should when they’re sent.
Litmus allows us to preview screenshots of our emails across 90+ apps and devices. Builder and Checklist are particularly handy for troubleshooting bugs and circulating email code. Papercut allows us to test emails from our code base. Good for making sure templates are built properly, personalized data populates, and email triggers work.