Why don’t the fonts look right in my email tests?

… because email design is the worst.

Time for another edition of “Lance’s Long-Winded Emails,” where Lance writes an elegant, wisdom-packed email to a client, & then pastes it right into our blog so that the world can benefit from Ascent’s transcendant brainpower.

Designing for email is a challenge unlike any other in digital design, and by far the most annoying. The technology used for email clients – most glaringly Microsoft Outlook – is hopelessly out of date. The ability for MS Outlook to render emails is roughly the equivalent of a 25+ year old web browser. Made by Miscrosoft. We’re talking Internet Explorer 5 type of capability here. Despite time marching on and incredible advances in technology and software, email designers still need to live in the world of HTML tables, basic CSS styles, and no interactivity. The limitations of the software strangle creativity and drive up costs for clients to communicate. It is downright criminal.

Fonts can’t be guaranteed to render properly unless they’re ultra-basic web safe system fonts

Even at the most basic level of text rendering, emails need to be painfully basic.

The only fonts that can truly be trusted to render perfectly are “system” fonts – referred to as “web safe” fonts such as Arial/Helvetica, Tahoma, Times New Roman, etc. Those fonts are installed on every Mac/PC device. All other fonts will only display if they’re installed on a user’s device or if they’re able to be embedded or “pulled in” externally/remotely. Many email clients do not allow fonts to be embedded. Remarkably, even Gmail (a Google product) does not allow emails to render Google Fonts (a Google product)!! That’s right – Google blocks itself and we all pay the price by seeing boring-looking emails.

If the email client doesn’t allow those embedded fonts, they strip the references to the external font and for all intents & purposes, the result is that the client “swaps” the font with an alternative. The only way a designer can guarantee that their creative font selection is rendered properly is if it is rendered as an image. But even then, it’s not going to be seen by all users, because Outlook won’t download that image without a separate click! And to make matters worse, your content existing only in an image creates usability problems.

The “Solution:” stack up & get in-line

For all the reasons above, emails – and websites too – should be coded with their text styles being fully defined with a “font stack,” instructing the user’s software which fonts to use as secondary options if the desired font is unavailable. That font stack should then be defined in-line in an email, so that you leave as little as possible to chance or interpretation by the client – and have less chance of important style information being stripped.

For example, if your email’s design uses Poppins (a Google font), then your paragraph code would read:

<p style="font-family:Poppins, Arial, Helvetica, Sans-Serif;">This is my paragraph.</p>

That stack tells the user’s software:

• Use Poppins if possible — if the font is installed on the device (not very likely) OR the software allows external fonts (such as iPhone)
• If Poppins is not possible, then use the next font in the stack instead – Arial (if the user is on PC) or Helvetica (if they’re on Mac)
• If for some crazy reason even those fonts aren’t available – perhaps the user is an alien or has traveled back in time to the early ’90s, then the software should render the device’s default Sans-Serif font.

What if you don’t?

If the font stack is not defined, or if the code that defined it got stripped, the worst case scenario is that the client has no idea what font to use, so it renders the text with its most basic default system font of all – typically a Serif such as Times New Roman on PC. That was a nice email we had once.

Test for All Reasonable Situations

To be as sure as possible that your email will render properly, test it using a dedicated service such as Litmus or Email on Acid. If you’re building the email the old fashioned way, coding with HTML, be sure to test both before and after the email is imported into the system that will deploy it. Your email might ace a test when sent via Constant Contact but bomb when it’s sent via HubSpot – it all depends how each system processes (and potentially manipulates) the HTML as it’s imported. You could be in for a world of hurt if you assume that the same email will render identically when imported into two different systems.