This article is part of a series that answers newsletter questions we often hear from users. Send us any questions you'd like us to answer!*
I regret to inform you that there’s no guarantee that the font you chose when drafting your newsletter is the same one subscribers will see in their inbox. I mean, you’ve got a pretty good shot if you pick one of the boring, omnipresent fonts, but not even that is a sure thing.
Every email client allows and disallows different types of content. Gmail clips messages short after a certain length. Apple Mail allows SVG images while almost every other client blocks them. And when it comes to rendering custom fonts, support among different clients is all over the map, so let’s start there.
Which email clients support custom fonts?
Email clients are constantly updating what they support and caniemail.com is the best place to keep tabs on those changes. It’s managed almost entirely by one person aided by community contributions, so it’s not perfect, but it’s the best we have.
The most widely supported way to add custom fonts to your newsletter is by customizing your CSS with a @font-face block. This approach gives clients a URL that points to where they can download your custom font. By caniemail.com’s estimate, fewer than 25% of clients recognize @font-face at all, with fewer than 22% fully supporting it.
When I tested it, Apple Mail and Thunderbird rendered custom fonts without any issues. But I couldn’t get Gmail, Proton Mail, Yahoo, or Outlook.com to display anything that wasn’t included in their list of supported defaults. The latest updates from caniemail.com for @font-face show zero support in Outlook macOS, iOS, Android, and Windows, but I wasn’t able to test them myself.
So, what happens when you send a newsletter formatted in a font that a subscriber’s email client doesn’t support? It’s complicated.
Fallback fonts and client defaults
When you send a newsletter with @font-face to an email client that doesn’t support it, the client will first look for a fallback font in your CSS. If there isn’t a fallback, a client will use its default font.
You can set your own fallbacks by adding a font-family list to your CSS with preferences in descending order. That would mean that font-family: 'Montserrat', Roboto, Arial; would tell a client to try Montserrat first, followed by Roboto, then Arial as a last resort. And since your sending platform is heavily incentivized to prevent you from sending unreadable emails (especially if you’re sending from a shared domain) there also may be a backup font-family hidden in your platform’s underlying template, just in case.
It’s only when you try to send a custom font to an email client that doesn’t support it and there are no fallback fonts that you hit rock bottom with the client default. Surely there’s a standardized default? Of course not! Some of the biggest names in email testing can’t even agree on defaults across platforms, with Email on Acid claiming Gmail uses Roboto and Outlook lands on Calibri, while Litmus claims it’s Arial and Times New Roman, respectively.
It is way harder than it should be to determine exactly how your newsletter will look in your subscribers’ inboxes. That’s why most sending platforms (not just Buttondown!) only include a small number of font options in their editors.
If you want to make your newsletter as accessible as possible, all you need to do is stick with your sending platform’s default options. Save your fancy custom font for designing your web archives (every major browser recognizes @font-face without issue).
But if you are dead set on trying to show subscribers a custom font, there are a few critical inclusions for avoiding potential blowback.
The safest way to add “unsafe” fonts to your newsletter
Before experimenting with editing any CSS settings, put your newsletter in Test Mode (or your platform’s equivalent) so you don’t accidentally email your entire list.
Next, you’ll need a URL to point subscribers’ clients to your custom font. One of the largest and easiest directories to work with is fonts.google.com, where you can search, filter, or browse to find an option you like. Click on the font you want, find the Get font, select Get embed code, and copy the URL that includes the font’s name. On Geist Pixel’s font page, for example, you’d grab:
https://fonts.googleapis.com/css2?family=Geist+Pixel&display=swap
Next, paste your font’s URL into a new browser tab. That should open a plaintext page with some CSS you will copy and paste into your custom CSS in your newsletter platform’s email design settings. These blocks (there are usually more than one and you’ll want to copy all of them) tell clients the name of your custom font (the value next to font-family:), its attributes, and its URL.
To instruct clients what types of text should be formatted in your custom font, paste something like this in your CSS, below the @font-face blocks:
After saving, any email client that supports @font-face will display your H1s, H2s, H3s, and paragraph text in Geist Pixel (or whatever custom font you chose). Make sure that it is easy to read, fixing any low-contrast colors and adding a font-weight to your CSS if the characters are too thin.
Gmail, Proton Mail, Yahoo, Outlook.com, and several other niche clients will format text with one of your fallback fonts, if they support at least one of them. Ideally, all of your fallbacks should be as close to your custom font as possible to avoid mismatched spacing and alignment that break the flow of text, since two fonts set to the same size might actually look significantly different. Font Style Matcher is excellent for comparing the same text in two different fonts and finding the closest matching font-size, line-height, and other CSS values between them.
You could use an image of text written in your custom font as a last resort. But even if you add alt text to the image, that approach still goes against WCAG standards.
You never know what client or settings a subscriber might have installed. The best you can do is include at least one of Email on Acid’s recommended fallback fonts:
- Arial
- Courier New
- Georgia
- Times New Roman
- Trebuchet MS
- Verdana
When drafting your test email, some newsletter platforms, like Buttondown, will show your custom font in the preview pane before sending. Others will display the fallback even if the custom font is OK to send. Still, the only way to get an idea of what a subscriber will see in their inbox is to view a test email in their client of choice, whether that’s on desktop or mobile, in a browser or an app.
Your font is not your message
There are a dozen reasons not to use a custom font in your newsletter. Subscribers’ clients may not support it. It’s almost certainly harder to read than one of the defaults for those who can see your words formatted the way you wanted them. It adds yet another layer of tracking in your emails. It makes you dependent on a URL that you don’t control and might stop working. The list goes on and on.
So yes, you can add a custom font to your newsletter. But you shouldn’t. While a few people might appreciate beautiful typography, everyone hates hard to read emails.
| Image | Credit |
|---|---|
| Header photo by Behnam Norouzi |