Emails don’t need to look the same in every email client, but there are some guidelines to make sure they render properly in email clients and are as accessible as possible.
General rules and principles
Cerberus strives 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). It’s safest to code emails like it’s 1999 (still).
- CSS2 instead of CSS3
<table>s instead of
- Raster images (like PNGs) instead of vector (like SVGs)
- Inline CSS instead of embedded styles or external stylesheets
HTML and CSS
<table border="0" cellpadding="0" cellspacing="0" role="presentation">when creating new tables. This negates any unwanted spacing and borders and tells screen readers to skip over the table’s tags and move straight into the content.
- When in doubt, nest another table. For finer control of your HTML, nest tables when building emails.
- Use padding for spacing in table cells. Margins aren’t fully supported on tables and container elements.
- Use margin for typography. Margins are fully supported for headlines, paragraphs, and lists.
alignfor layout instead of
flexbox. Floats aren’t supported in Outlook and email clients don’t have good support for modern CSS layout properties in general.
- HTML attributes are still relevant. Most styling is done using CSS. But because some email clients use antiquated rendering engines, they tend to better understand HTML attributes like
- Define color as
rgb(1,2,3). Six-digit hex is supported in inline CSS as well as HTML attributes like
bgcolorthat are still supported in email.
- Don’t forget about preview text. 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.
- Save images as PNG, GIF, or JPG instead of SVG. SVG has almost no support in email, no matter how it’s referenced (inline, Base64,
- Save images as @2x and scale them down using HTML attributes. 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"on all tables used for layout. This prevents screen readers from reading aloud the structure of each table cell.
aria-hidden="true"on presentational elements. This prevents screen readers from reading aloud something that's not content.
- Use HTML1 semantic tags whenever possible. Tags like
<h>allow screen readers to quickly jump from section to section. Tags like
<em>give text more importance.
- Include an
altattribute on every image. Be descriptive and use
altto 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
altattribute (eg. "icon dash checkmark dot png"). More on alt text.
- Avoid “Click Here” or “Learn More” link copy. It helps an email avoid spam filters and gives context about the link to folks using screen readers or dictation software.
- Create a plain text version of every email. 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.
Tools to ensure emails look as they should when they’re sent.
- Litmus and Email on Acid allow us to preview screenshots of our emails across 90+ email clients on multiple devices. Both have code editors built in (Eg. Litmus Builder), which helps troubleshoot and fix bugs in actual email clients.
- Parcel - A web-based code editor built specifically for email development.
- Putsmail - Send yourself test emails.