There is no such thing as a “web safe font”. There, I said it. I’ve seen so many posts asking for safe fonts to use in HTML emails, usually answered with a reduced list of fonts available on Windows. So let me explain why safe fonts is a fallacious concept and how much more there can be to fonts in HTML emails than Arial and Times.
Fonts in an HTML email can come from four different sources:
- System fonts
- User fonts
- Email Client fonts
- Embedded fonts
Let’s talk about each of those.
1. System Fonts
Every operating system comes with a default set of fonts available throughout the entire system. Here are links to the full list of available fonts provided by system vendors.
macOS Catalina provides a staggering amount of 520 preinstalled fonts. iOS 13 follows with 273 preinstalled fonts. Windows 10 has 183 fonts. And Android has… 9 font families.
Android is a special case because there’s not one true version of Android. Default fonts will vary if you have a Samsung, Xiaomi, or Google device. While Apple and Microsoft provide very clear lists of the default fonts installed on their systems, I haven’t been able to find such a list for any maker of Android devices. (Google only has a list from way back to Android 4.1).
With so little fonts available on Android, it should be clear now why talking about “safe fonts” make little to no sense. Even Arial or Times New Roman are absent from Android, thus falling back to respectively Roboto and Noto Serif.
2. User Fonts
You can install your own fonts in any system these days. Download a font you like from Google Fonts, Adobe, DaFont or whatever is your favorite foundry, install it, and it now becomes available throughout your entire system.
While this has been possible pretty much since dawn in operating systems like Windows, macOS or Android, it’s only been possible in iOS since iOS 13 (in 2019). For example, you can install Adobe Creative Cloud on iOS and download and install any new font from there, making it available in any other iOS app.
3. Email Client Fonts
Email clients can also come with their own fonts. This is true for native applications, but also for any web email client. For example, Gmail’s desktop webmail embeds its own version of Google Sans (in Regular, Medium) and Roboto (in Regular, Medium, Bold). Outlook.com’s desktop webmail embeds Segoe UI Web (in Regular, Semilight, Semibold) and the Shell Fabric MDL2 Icons icon font.
4. Embedded Fonts
Why don’t more email clients support embedded fonts? I can’t speak for them. But my guess is it all comes down to security. Font files are nothing more than little executable software in themselves. And just like any software, they’re vulnerable and can thus bring their vulnerabilities into any software that embeds them. (See this StackExchange thread for a lot of examples.)
Best practices for setting fonts in HTML emails
fontshorthand property has very good support. So instead of declaring individual properties (like
font-family:sans-serif; font-size:16px; line-height:24px; font-weight:bold;), you can declare a single
font:bold 16px/24px sans-serif). It’s shorter, cleaner. I like it.
- Always declare a generic font family name as a fallback. If you omit it, the rendering engine will use whatever is the default font. For example, in a modern browser,
font-family:Lobsterwill render as
font-family:Lobster, sans-serifwill render as either Arial, Helvetica or Roboto depending on your system.
- If you use a
@font-facedeclaration, include the properties
mso-font-altto better control the fallback font in The Outlooks on Windows. (You can read about the day I learned about
- Font Style Matcher by Monica Dinculescu is a great tool to find a fallback font not too different from the web font you want to use.
Font Family Reunion by Zach Leat is a great tool to see which system font you’ll get from a