FEDTalk: How to use web fonts in email
You know how it goes; you’re in the flow, cranking out code. Then, a ticket from the Creative Department shows up in your inbox; they have a flashy new email design to be built out to go along with your latest rebranding efforts. You review the layout and read through the specifications and notice that they’re calling for the use of some… unusual fonts that you haven’t seen before. You send a note back, asking where these fonts came from. “They’re the web fonts we’ve adopted as part of our new branding”, they respond, “and it’s critical they are used in our upcoming launch.”
Great. Now what?
Web Fonts vs. Web-Safe Fonts
Before we get into the “how”, let’s first discuss the “why”. For a very long time, emails have been limited to the fonts that are installed by default on user’s computers. When you hear “web-safe fonts”, that’s what the term is referring to. The most common are:
| Sans Serif | Serif | Monospace | Script |
|---|---|---|---|
| Arial Helvetica Verdana Trebuchet MS Tahoma |
Times New Roman Times Georgia Courier Courier New |
Courier Courier New |
Brush Script MT Comic Sans |
That’s a decent list, but it doesn’t allow for much differentiation. You’ll notice, if you look at enough emails, that they all start to look the same, at least from a typographical point of view. Arial is the most widely used font online*; anywhere you look, you’re likely to see it, including email. If it’s not Arial, it’s Verdana or Tahoma. For serif fonts, you’re going to see Times New Roman most often; not only is it widely used from a design standpoint, but it’s also most frequently used as a default for when other fonts fail to load (which is something we’ll discuss later).
*Per https://www.cssfontstack.com/
So how do you make your emails stand out more in the inbox? The use of different fonts can help differentiate your emails from the rest just as much as an eye-catching layout. More importantly, web fonts allow your branding to carry over without having to rely on images, which may be turned off by default on the recipient’s email client, and cause potential accessibility issues.
Okay, but email development is still stuck in the ‘90s, at best. Do web fonts work in email?
As with so many questions in Marketing, it depends. The main sticking point is going to be what email clients your recipients are using. But before we open that can of worms, let’s first discuss how to use them in the first place.
Where do they come from?
Most commonly, web fonts are hosted on a commercial service and loaded into the asset; the most common are Google Fonts (free) and Adobe Fonts (not free); there are other font services available as well. You can also host the font files on your own servers if you have the license to do so.
Something to keep in mind regarding licenses: it’s very important to note that not all font licenses include online usage in their agreements, and those that do often have a certain limit on the amount of page views. In the case of emails, every time an email is opened counts as a page view, so if you have an email going out to a million contacts, that’s the potential for a million page views in one shot. And some licenses differentiate between use in web pages versus use in emails, so be sure to check.
What email clients support them?
Only certain email clients can support web fonts, and some of the ones that don’t may surprise you (although if you’ve done email marketing for any length of time, some of them won’t).
| Email Client | Supports web fonts |
|---|---|
| Apple Mail (macOS, iOS) | Yes |
| Gmail (webmail, iOS, Android) | No |
| Outlook (2007 and later) | No |
| Outlook for Mac | Yes |
| Outlook Office 365 | No |
| Outlook app | No |
| Outlook.com | No |
| Samsung Mail | Yes, but only if you’re not using a Microsoft email address |
| Yahoo! Mail | No |
| AOL Mail | No |
| Thunderbird | Yes |
For those email clients that are listed as “no” above, we’ll discuss any known issues and/or possible workarounds for them a little later. It may also be worth looking at any metrics you have on which email clients your recipients are using to see if it’s worth the effort of implementation.
How do we use them?
Get the font file’s URL
To use web fonts in email, as in web pages, you’ll need a URL that references the font file(s) that you want to use. You should be able to get this from the service providing your fonts, or from your IT team if they’re being self-hosted. If you’re using Google Fonts, we’ll get there in a minute.
Embed the fonts into your email
Here’s where things start to get a little tricky. If you’ve worked with web pages before, you’ll know that there are three different methods to embed web fonts:
- <link>
- @import
- @font-face
Which one you decide to use will depend on several factors, including email client compatibility, ESP compatibility, where the fonts are hosted, and load time.
For the following examples, we’re going to work with “Poppins”, a nice sans-serif font created by Jonny Pinhorn for Indian Type Foundry, and is available via Google Fonts.
The <link> method
This is one of the easiest ways to get your web font into your email. Google Fonts provides the code that you’ll need to implement this method.
Once you get the code, copy it and paste it into your email’s <head> section. Done!
A positive about this method is that it enjoys good support among email clients; if the client supports web fonts, it will support the <link> method. The downsides are:
- It doesn’t support self-hosted fonts without some extra effort to create the stylesheet.
- It loads the fonts before the rest of the email, which can slow down the email rendering if you’re loading a particularly large font or multiple fonts.
The @import method
This is also easy and works very similarly to the <link> method above. Again, Google Fonts provides the line of code you’ll need to implement this method. This time, it will need to be placed within <style> tags in the <head> of your email; if you have other CSS rules in your email already, place this at the top of the block.
The downsides of this method are:
- Loading the web font is deferred until the rest of the email’s HTML is loaded, which can lead to the email displaying before the font has finished loading.
- It also doesn’t support self-hosted fonts.
The @font-face method
This method is the more hands-on way to implement web fonts in email, but it offers the most flexibility of the three. How, you may ask? Font format choice!
There are five common formats for web fonts:
- .eot
- .woff
- .woff2
- .svg
- .ttf
When considering compatibility with email clients, the .woff and .woff2 formats are the most widely supported. Why does this matter? Well, the @font-face method is the only one of the three that lets you choose the formats to use, which helps to ensure that your selected fonts will be displayed correctly in the email clients which support them.
Remember when I said it was a little more hands-on? Let’s look at how this method works. You’ll need to add an @font-face declaration to your <style> block in the email; here’s what it would look like for Poppins:
You can see that the font family name is set, what style and weight are being declared, and finally the source URL for where the font file is located, along with its format. And if you’re wanting to use self-hosted fonts, this is the method to use.
You can also use Google Fonts with this method, although it involves a little more legwork to implement:
- Open the font in Google Fonts that you want to use, and choose the styles you want to use. In the <link> code that is provided, copy the URL in the href.
- Once copied, open a new browser tab or window, paste the URL into the location bar, and hit Enter. The stylesheet that Google uses to load the fonts will be displayed:
- Copy the entire @font-face declaration below the “latin” comment and paste it into the <style> block in your email’s <head>. Done!
If you’re using Google fonts with this method, it’s important to note that the URL Google uses for the individual font files may change from time to time, so it’s important to periodically check to make sure that they still work.
This method also allows you to use actual bold and italics in your emails by pulling in the appropriate versions of the fonts, if they’re available. Just create additional @font-face declarations for each version:
Note that for “bold” versions, the font-style is set at “normal”, and the font-weight is set to 700; for “italic” versions, the font-style is set at “italic”, and the font-weight is set to either 400 or 700. Note also that the font-family name is consistent throughout.
Kudos to email accessibility advocate Paul Airy for coming up with this method of importing web fonts, as documented in an issue of Litmus’ Type: E newsletter.
Pick a fallback font
A fallback font is a web-safe font alternative that should display for email clients that don’t offer support for web fonts. Different email clients have different default fonts, but you can specify what web-safe font should be used as well.
It should go without saying that a fallback font should be in the same category as the original, e.g. sans-serif, serif, etc. Another important consideration is the fonts’ respective x-heights, which is the vertical height of the font as measured by the lowercase letter “x”. You should pick a font whose x-height is close to that of the web font so that the email’s layout doesn’t do Terrible Things™ should the web font fail to load.
In the following example, we can see Poppins on the left, followed by Arial and Tahoma. You can see that Arial is a little shorter than Poppins’ x-height, but Tahoma’s is right on the money, so that would be the better choice in this case.
Putting web fonts to work
Now that we have all the setup completed, we can put the web fonts into the email. Use the font-family name defined in your import method, followed by your fallback font(s) to style your desired elements:
font-family: ‘Poppins’, Tahoma, sans-serif;
If Poppins isn’t available or web fonts aren’t supported, the next font in the list will be used, and so on. That’s it.
Workarounds for email clients that don’t support web fonts
Outlook
Web fonts aren’t supported in Outlook, but on top of that disappointment, there’s another weird quirk to deal with in older versions of the application.
If you use the <link> or @import methods, Litmus discovered that any Outlook version before 2019 will display Times New Roman for anything that has a web font applied, ignoring any fallback fonts declared. Neat, huh?
Thankfully, there is a workaround for this, and that’s to use the @font-face method to declare your web fonts; Outlook will then honor your fallback font selections. However, if you must use one of the other two methods, you’ll need to hide that section of your styling from Outlook using Microsoft Office conditional code. In the following example:
Becomes…
It’s a little ugly, but it works.
You can also use the mso-font-alt property inside the @font-face declaration to set a fallback font for Outlook directly in the CSS, which is handy.
It’s interesting to note that Outlook 2019 and later will use your fallback fonts without the MSO conditionals, so it looks like there might be early attempts being made to support web fonts in Outlook…?
What about Gmail and the rest?
Unfortunately, Gmail doesn’t support any web fonts, with the exception of Roboto and Google Sans, since they’re included in the email client’s styles. Not even Google Fonts. Weird, but true.
Yahoo! Mail and AOL Mail currently have no known workarounds.
Wrapping it up
Web fonts are a great way to have your branding to carry through your emails without having to rely on images, which may not load and aren’t as accessible. That said, they’re not going to work universally for all of your recipients, so it’s always important to test, test, test!
If you need help implementing web fonts for your emails, or assistance with making sure your branding is carried through all your marketing automation efforts, Relationship One is here to help!
References:
