You spent hours designing an HTML email with beautiful typography, only to find out it renders in Times New Roman for half your subscribers. Frustrating, right? Web fonts in HTML emails let you control the look and feel of your message beyond the handful of system fonts every device already has. They help reinforce brand identity, improve readability, and make your emails stand out in a crowded inbox. But embedding them correctly is tricky because email clients handle fonts very differently from web browsers. This guide walks you through exactly how to do it, what works where, and what to watch out for.

What does it mean to embed web fonts in HTML emails?

Embedding a web font in an HTML email means loading a font file usually hosted on a server or a CDN like Google Fonts directly into your email's code so the text renders in that specific typeface. Unlike system fonts such as Arial or Georgia that already exist on a user's device, web fonts must be downloaded before they can display. In a regular website, this happens automatically. In email, the rules are different because most email clients block or ignore external resource loading for security reasons.

When you embed a web font, you typically use a @import rule or a <link> tag in your email's <head> section to pull in the font from an external source. Then you apply it with CSS using font-family. If the email client supports it, your custom font shows up. If it doesn't, a fallback font takes its place.

Which email clients actually support web fonts?

This is the most important question because support is inconsistent. Here's a quick breakdown:

  • Supports web fonts: Apple Mail, iOS Mail, Outlook (macOS and iOS), Thunderbird, Samsung Mail, and the default Android mail app.
  • Does NOT support web fonts: Gmail (all platforms), Outlook (Windows desktop), Yahoo Mail, and AOL Mail.

That means a significant portion of your audience will likely see your fallback fonts. This isn't a reason to skip web fonts entirely it just means you need to choose your fallbacks carefully so the email still looks good even without the custom typeface. If you want to understand which specific typefaces hold up well across clients, check out this breakdown of email-safe web fonts that render correctly across all email clients.

How do you actually embed a web font in an email?

There are three common methods, and the one you pick depends on your email platform and comfort level with code.

Method 1: Using @import in your CSS

This is the simplest approach. You add an @import statement at the top of your embedded <style> block inside the email's <head>. For example, to use Open Sans from Google Fonts:

<style>
@import url('https://fonts.googleapis.com/css2?family=Open+Sans:wght@400;700&display=swap');
body { font-family: 'Open Sans', Arial, sans-serif; }
</style>

The @import method works in Apple Mail, iOS Mail, and Outlook on Mac. It will not load in Gmail or desktop Outlook.

Method 2: Using a link tag

Some email developers prefer placing a <link> tag directly in the <head>:

<link href="https://fonts.googleapis.com/css2?family=Lato:wght@400;700&display=swap" rel="stylesheet">

Then reference Lato in your CSS the same way. Both @import and <link> have similar support levels, though some testing platforms show @import as slightly more reliable in Outlook on Apple devices.

Method 3: Using @font-face

If you self-host the font file (on your own server or a CDN), you can use @font-face to define the font directly:

@font-face {
  font-family: 'CustomFont';
  src: url('https://yourserver.com/fonts/customfont.woff2') format('woff2');
}

This gives you more control but requires you to manage hosting and file format compatibility. Make sure to serve .woff and .woff2 formats, as older .ttf files may not work everywhere.

How do you set up fallback fonts properly?

Since web fonts won't load everywhere, your fallback stack matters a lot. A fallback font stack tells the email client which fonts to try next if the web font fails. Here's an example:

font-family: 'Montserrat', Arial, Helvetica, sans-serif;

If Montserrat doesn't load, the client tries Arial, then Helvetica, then whatever generic sans-serif the system has. The key is choosing fallbacks that match your web font's proportions similar x-height, weight, and letter spacing so the layout doesn't break.

If you're not sure which pairs work well together, this resource on accessible font pairings for marketing emails covers solid combinations that keep your design intact no matter what renders.

What are the most common mistakes people make?

Here are the errors that trip up most email designers when working with custom fonts:

  • Not testing fallback fonts: Designers focus on the custom font and forget to check what the email looks like when it doesn't load. Always preview your email with fallback fonts only.
  • Relying on Google Fonts alone: Google Fonts is the most popular source, but it's blocked by some email clients. Don't treat it as guaranteed.
  • Using fonts that only come in one weight: If your design needs bold and regular text, make sure the font you choose includes both. Roboto, for instance, comes in a wide range of weights, which makes it flexible for email.
  • Ignoring file size: Loading multiple font weights or styles increases download time. Only include the weights you actually use. If your email only needs regular and bold, don't load light, semibold, and black too.
  • Forgetting dark mode: Some email clients invert colors in dark mode, which can affect how your font renders visually, especially thin-weight fonts.
  • Skipping inline CSS: Many email clients strip out <style> blocks entirely. While the @import needs to stay in the <head>, make sure your font-family declarations are also applied inline on key elements as a safety net.

Should you use serif or sans-serif web fonts for email?

It depends on your brand and the context of the email. Sans-serif fonts like Poppins tend to read better on screens at smaller sizes, which makes them a safe default for body text. Serif fonts like Merriweather can work well for headlines or brands that want a more editorial or traditional tone. The key is understanding how each category behaves across clients. This comparison of serif vs. sans-serif fonts for email newsletters breaks down the tradeoffs in detail.

Which fonts from Google Fonts work best in email?

Not all Google Fonts are equal in an email context. Some have better cross-client support because of how they're encoded or how widely they're used. Here are a few that consistently perform well:

  • Open Sans clean, versatile, and widely tested
  • Roboto neutral and readable at small sizes
  • Lato friendly and works well for both headings and body
  • Montserrat modern geometric sans-serif, great for headlines

When picking a font, also check that the license permits use in email. Most Google Fonts are open source (SIL Open Font License or Apache License), but always verify before sending commercial campaigns.

How do you test web fonts in emails before sending?

Testing is non-negotiable. Here's a process that works:

  1. Use an email testing tool: Platforms like Litmus or Email on Acid render your email across dozens of clients and devices so you can see exactly where the web font loads and where it doesn't.
  2. Send real test emails: Preview tools aren't always accurate. Send actual emails to test accounts on Gmail, Outlook, Apple Mail, and Yahoo to check rendering.
  3. Check with images off: Some users have images disabled, which doesn't directly affect fonts but can impact your overall layout assumptions.
  4. Test your fallback stack separately: Temporarily remove the web font @import line and see how the email looks with only fallback fonts. If it still looks professional, your fallback stack is solid.

Quick checklist before you send

  • Font is loaded via @import, <link>, or @font-face in the <head>
  • Fallback font stack matches the proportions of your web font
  • font-family is applied both in the <style> block and inline on key elements
  • Only the weights you need are included in the request
  • You've tested across Gmail, Outlook (Windows), Apple Mail, and at least one mobile client
  • The email still looks professional with fallback fonts only
  • Font license allows email use

Start by embedding one web font in your next campaign, test it thoroughly, and adjust your fallback stack based on what you see. Small, careful changes beat big redesigns every time.

Try It Free