Web Fonts: How to Make Them Work Perfectly in Email

One of the first aspects of design that people play with is typography–and it’s important in email design, too. But accessibility is also critical delivering a great subscriber experience. To deliver on both, stop  trapping your message in images, and start using live text with web safe fonts and web fonts.

Read on to learn exactly how to do it:

• Web fonts vs. web safe fonts
• The benefits of web fonts
• Email client support and licensing
• Where to find web fonts
• Coding them into emails
• Great examples of web fonts in email

Web fonts vs. web safe fonts

There are two different ways you can do live text: web safe fonts and web fonts. Although they sound the same, there are definite differences. In order to understand these differences, let’s take a look at how fonts work in your emails.

When your email is coded, the font is declared using a CSS property called font-family. This font-family property can have just one font name or multiple font names—often referred to as a font stack. Including multiple font names ensures that if one font doesn’t work, there is a fallback or backup font of your choosing. Without listing multiple font names, the email client gets to decide your backup font. When your subscribers open your email, the browser reads the font-family property and pulls in the font to use.

Web safe fonts

With web safe fonts, the browser pulls the font from your local font directory. That means these are fonts that are already installed on your computer. All computers come with pre-installed fonts, and these are what’s considered web safe. They’re safe to use because there’s a really good chance your subscribers will already have them.

The downside is that there are a limited number of web safe fonts compared to web fonts. And they’re used pretty frequently, so you’re less likely to stand out (if that’s what you’re aiming for).

The obvious web safe fonts are:

• Arial
• Helvetica
• Verdana
• Georgia
• Times New Roman

But there are several other ones out there that you can use with a certain degree of confidence. So break out of the standard Arial or Helvetica font loop, and find a web safe font that works for your brand.

The best resource I’ve found for web safe fonts is CSS Fonts. I love that they include a percentage of use for PCs and Macs for each font so you know approximately how many of your subscribers might see the font you want and how many will see your fallback instead.

Web fonts

Web fonts are pulled from a server—either one you host yourself or an external one (such as Google or Adobe). Because of this, the variety of fonts that can be used is much larger, and they can be used on any computer… as long as the browser or email client can pull the font in. In some cases, your subscriber may already have a web font downloaded and installed on their machine, so these fonts will work even in email clients that don’t support web fonts!

So while web fonts give you much more variety and creative freedom, they do come at a cost: limited email client support (which I dive into further down).

Why web fonts?

So you might wonder, why bother with web fonts at all? As a marketer and designer, you know the pressure to stay on-brand in email with colors, design, and—yes—typography. Web fonts let you show off your brand without relying on images for your text.

Locking important copy in images has been a standard practice in email design as a way of staying on brand and being creative. But “hiding” text in images limits the accessibility of the email because screen readers can’t read the text on the image.

And, having text in your images hurts the subscriber experience if they have images turned off by default. This may not be a huge portion of your subscribers–but there’s really no way to know if someone has their images turned off and opens your email. So why not provide the best experience for the widest audience possible?

Web fonts open up new avenues of creativity in typography, allowing email designers to be creative and accessible—and stick to their brand’s look and feel.

Can I use web fonts in email?

If you haven’t already guessed, the answer is yes! But—as in all things email—there are caveats.

Email client support

Web fonts only work in some email clients, and care has to be taken to ensure that where they aren’t supported, the font falls back gracefully.

*Has some wonky results depending on email embed method, discussed later.

It’s worth taking a look at your subscriber base to see how many are viewing your emails in an email client that supports web fonts. If enough of your subscribers are, it’s an opportunity to give your email an added touch. (If the majority aren’t, it may not be worth your time and effort–especially if you’re considering using a paid web font).

Which email clients do your subscribers use? Find out where your subscribers open your emails and how they engage—with Litmus Email Analytics. Get the insights you need to optimize your emails and beyond. Learn more →

Licensing

Web fonts were originally designed to be used solely on websites, so their licensing is typically for use only on websites and mobile applications. The reason many web font services didn’t allow use in email is because it’s seen as distributing the font, which goes against many of the services’ End User License Agreement (EULA).

All of the web font providers we contacted supported using their fonts in email. Each provider had a different license that was required, so there isn’t a standard way fonts are licensed in email. If you are looking to use a font, reach out to the company to find out exactly how they license their fonts.

Where to find web fonts

So you’ve thought everything through and decided you want to give web fonts a go. With seemingly endless options, you can find ones to fit your brand. But it’s also important to keep accessibility in mind.

Some fonts are easier to read than others.

Ornate or decorative fonts, such as display or handwriting fonts, can make it difficult for people with visual impairments or dyslexia to tell the difference between letter shapes. Sans-serif fonts (fonts without extended features or curls in their letters such as Arial, Calibri, Century Gothic, or Helvetica) and slab fonts (fonts with thicker lines such as Museo Slab and Rockwell) are considered more accessible.

Here are a few good places to start looking.

Google Fonts

There are loads of web font services available, but Google Fonts is our favorite. The service is totally free, and you can download the web fonts to your computer if you’re mocking up designs in Adobe Photoshop, Sketch, or another design software.

Adobe Fonts

Typekit has become Adobe Fonts as of October 2018. They now support both the <link> and the @import method for using fonts as web fonts (more on that next). The service isn’t completely free, but if you’ve already got any Creative Cloud subscription, it’s included with that.

Web font services

There are several other web font services available on a paid basis. You’ll need to make sure you get the correct license to use them in your email.

• Type Network (Web License)
• Process Type Foundry (Web License)
• Optimo (Digital Ads License)
• Fontspring (Custom Email License)
• Typotheque (Web License)
• Production Type (Online Advertising License)
• MyFonts (Web License)
• Commercial Type (Web License)

With the web licenses, there may be a choice to host the font yourself or to have the font hosted by the provider. In some web licenses, you pay for a certain amount of page views with each email that loads the font counting as a page view, so make sure you take that into consideration when you are purchasing a license.

How to embed web fonts in emails

Because web fonts typically aren’t found on someone’s local device and instead are hosted elsewhere, you have to “embed” or import your web font into your emails first before you can actually use them.

1. Get the URL of your font file

You’ll need your web font’s URL to call it into your email. Your web font service should have this URL. But if you’re hosting the font file yourself, get the URL from where the web font sits on your server. Make sure it’s a public URL and not coming from a local server. Otherwise, your subscribers won’t be able to access the web font and will see a fallback font instead.

If you’re using Google Fonts, finding the URL is a little tricky, but not too difficult. Find out how in the next step for the @font-face embed method.

2. Import the web font using one of three methods

There are three methods for embedding web fonts in email (and a caveat that may limit which method you can use). The three methods to embedding your font are:

• <link>
• @import
• @font-face

So why would you choose one method over another?

The @import method defers the loading of the web font that’s being imported until the HTML it’s embedded in is fully loaded. This can lead to your web font taking a little longer to appear in your email, while the rest of the email is loaded. Conversely, the <link> method loads the resource inline as the HTML file’s code is read (from top to bottom), which could delay the loading of your email if your web font file is particularly large.

Another thing to keep in mind when choosing a method to use is what your ESP supports.

You can make beautiful code that works in Litmus all day long, but if your ESP changes your code, as we know most of them do, then nothing you do will matter. Make sure your ESP doesn’t change your code in a way that would cause your fonts to stop working. At Litmus, our ESP doesn’t let us include MSO conditionals around style elements. So the <link> and the @import methods won’t work for us as they aren’t well supported in Outlook, which we discuss further below.

Using <link>

Using the <link> method is a relatively simple method for embedding fonts in your email. Place this line of code in the <head> of your email, near the top:

Using @import

The @import method is also a relatively simple method. Place this line of code in the <head> of your email between the <style> tags:

Using @font-face

Online web font services commonly offer five file formats to choose from: .eot, .woff, .woff2, .svg, and .ttf. The .woff and .woff2 formats have the best support when it comes to email, so we suggest using one or both of these formats when you can. The @font-face method is the only method that allows you to specifically choose what file format you’d like to import, making it the most bulletproof method for implementing web fonts.

Here’s a typical @font-face declaration for importing a web font into email using Google Fonts as our chosen web font service:

If you are using Google Fonts, finding the @font-face code isn’t the easiest, but it’s not too difficult.

First, you have to find the font you would like to use on Google Font. Then, choose the style you want to use. A flyout menu will appear on the right.

In the flyout, there will be a choice for <link> or @import. Both of these will have a URL (highlighted in the screenshot above). You can copy that URL and paste it in the address bar of your browser to find the CSS stylesheet that Google uses.

Copy and paste the ‘latin’ version of the @font-face between your <style> tags.

At Litmus, the @font-face method is our go-to implementation of importing web fonts into our emails.

All credit for this method of importing web fonts goes to email accessibility advocate Paul Airy, as detailed in a past Type: E newsletter.

3. Choose the right fallback font

When using web fonts, it’s a necessity to have a fallback web safe font in place for those email clients that don’t support web fonts.

Each email client has a default font if the font listed in the font-family stack is unavailable. For example, Gmail uses Arial, Apple Mail uses Helvetica, and Outlook uses Times New Roman. If you don’t like the sound of any of these default fonts, we’ve got some good news—you can choose your fallback font when you code in the font-family stack (in the next step).

Choosing the right fallback font that retains your email’s design is key to serving up a great experience for all your subscribers, no matter which email client they’re using.

Fallback fonts should be the same type as the web font—use a sans-serif fallback font if your web font is a sans-serif font, and a serif fallback font if your web font is also a serif font. Using the same style of font will help retain your email’s design in different email clients.

You can take it one step further by analyzing the x-height of the fonts.

The x-height is the vertical height of the font. Ideally, you should choose a fallback font that has a similar x-height to prevent your email design from falling apart when the fallback font is in use.

Here’s an example of the subtle differences in x-height between the fonts Verdana, Arial, and web font Proxima Nova. These subtle differences can make all the difference in making or breaking your email design when web fonts aren’t rendering.

4. Use your fonts in email

Once your web font is imported and your fallbacks chosen, using them in email is as easy as using a web safe font. Just use the font-family name defined in the import method followed by your fallback font(s) in either the CSS inline or in the head:

Think of this as a prioritized list of preferred fonts. If an email client can’t comply with your number one choice, it will fall back to the next one on your list.

For example, using the above font-family stack, Gmail will ignore the first font in the list as it’s a web font that’s not supported in Gmail. So the font rendered will be Verdana. If Verdana isn’t supported on the device used (which would be very rare since Verdana is a web safe font), the device would use the default sans-serif font for its system, as this is the third font in the list.

5. Avoid faux bold or faux italic

If you have accompanying bold and italic versions of your web font files, then let’s use them!

Typeface designers have put a lot of thought and effort into getting all the different styles of a font just right, so it’s best practice to apply the original type design rather than allowing the email client or browser to haphazardly apply a faux bold or faux italic to the regular font.

Basically, do NOT do this:

Like web design, you can pull in the genuine fonts by including these styles in your @font-face stack, like so:

As you can see, the different styles pull in different fonts regardless of the font-family. This way, if you style your font in the HTML like this:

…then it will pull in the genuine ‘Roboto-BoldItalic’ font! Likewise, just adding font-weight: bold; will pull in ‘Roboto-Bold’ and just adding font-style: italic; will pull in ‘Roboto-Italic’.

Do NOT do this, either!

So, you might be wondering—why do it this way instead of declaring a different font-family for each style, which also pulls in the genuine fonts? This is how that looks:

This presents a problem. Using font-family names to store styles not only creates overly-complicated and redundant CSS, but it also strips your text of styling if your fallbacks kick in. So for example—if you’re viewing the above code in Gmail (which doesn’t support custom web fonts), then you will only be seeing un-bolded, un-italicized Verdana instead of Roboto Bold Italic.

By keeping your font-family and your font-weights or font-styles separate, your fallback fonts will still retain the correct styling.

6. Use a fix for Outlook

Outlook has a wonderful quirk that you’ll want to watch out for. Especially if that’s what many of your subscribers use.

See how your emails look in Outlook and more Every email client has its quirks. Fortunately, you can see them in your emails before you hit send—with Litmus Email Previews. No more broken emails. Learn how →

If you use the <link> or @import method, everything before Outlook 2019 will display Times New Roman regardless of what fallbacks you put in for your font.

The simplest fix for this is to use the @font-face method. But if you need to use the <link> or @import method, then use Microsoft Office (MSO) conditionals to comment out that section of your styles. This will keep Outlook from seeing those, and it’ll use your fallback fonts as intended:

Without MSO conditionals	With MSO conditionals
<link rel="noopener" target="_blank" href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet">	<!--[if (gte mso 9)|(IE)]><!--> <link rel="noopener" target="_blank" href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet"> <!--<![endif]-->

But wait a minute. I just said everything before Outlook 2019. So what happens in Outlook 2019 (and Outlook Office 365)? Well, in those email clients, Outlook falls back to your fallback even without the MSO conditionals.

Without MSO conditionals	With MSO conditionals
<link rel="noopener" target="_blank" href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet"><!--	<!--[if (gte mso 9)|(IE)]><!--> <link rel="noopener" target="_blank" href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet"> <!--<![endif]--><!--

In fact, in those clients, the @import appears to actually work! But does it really? We tried it with other fonts, and the results were about on par with what you’d expect from Outlook:

It looks like sometimes it puts in a system font instead of the fonts you specify. And in the case of Montserrat, I’m not quite sure what is going on there, but that’s not Montserrat. It actually looks more like Lato. So it seems that Outlook is attempting to support web fonts, but it isn’t quite there yet. It’s definitely something to keep an eye out for in the future.

In the meantime, for the above reasons—and because you can’t target only Outlook 2019—it’s best to use @font-face or hide your <link> or @import declarations.

If you find Outlook converting your font to Times New Roman, you can add mso-font-alt: ‘Arial’; to the @font-face block to provide an alternative fallback for Outlook:

Another solution you could use is coding the font-family with the web safe font stack inline and including a <style> block to override the fonts with the web font. Then it’s just a matter of hiding that style block from Outlook:

7. Use a fix for Gmail, too (just kidding, there’s not one)

So you might be wondering, “What about Gmail? We are using Google Fonts after all.”

You’d think that as Gmail is a Google product and Google Fonts is a Google product, they’d play nicely together. But alas, that’s not the case.

Web fonts do not work in Gmail even if they are a Google Font and even if you use the code supplied by Google. The one exception for this is Roboto:

Using different Google Fonts	Using different embedding methods

And in fact, on Gmail Mail App on Android, all sans-serif fonts fall back to Roboto:

Using different Google Fonts	Using different embed methods

Some inspiration to get you started

Alright, now who’s ready to see a couple awesome examples of brands using web fonts in email the right way?

Ace Hardware used web fonts where they are supported, but chose Rockwell as a fallback slab font to ensure the email still looked on brand in other email clients.

With web fonts	With fallbacks

Webflow uses system fonts as a fallback for their web fonts and uses font weights to ensure a great typographic experience no matter what font appears.

Stay on-brand and error-free

Web fonts are a great way to keep the text in your emails both branded and accessible. But as you can see from this post, there are a lot of nuances to consider. That’s why it’s equally important to…

Always be testing!

We’ve done our best to test a bunch of different circumstances, but your ESP may distort your code in an unexpected way. Make sure to test your emails before sending them out to make sure all of your fallbacks are working properly.

QA test web fonts in your emails Did you do it right? Find out with a free trial of Litmus. Preview how your emails look in over 90 email clients, apps, and devices. And maintain your brand reputation with flawless emails. Start your free trial of Litmus →

Adding web fonts is worth it as a great progressive enhancement to help you provide the best experience for your subscribers in their inboxes. Have fun! And let us know if you have any questions or comments below.

Originally published on April 11, 2019, by Jaina Mistry. Last updated April 23, 2021.