Get Started

Email Fonts: Web-Safe, Web Fonts, and Fallback Stacks

Published

The font you choose is not the font everyone sees

You pick a beautiful typeface for your email, preview it in the builder, and it looks perfect. Then a reader on Outlook opens the same email and sees a completely different font — maybe Times New Roman, maybe something you didn’t choose at all. Your heading that was designed in a clean sans-serif now renders in a serif, and the careful spacing you tuned is gone.

This happens because email clients don’t all support custom fonts. The font you see in your design tool is the best-case scenario. What your readers actually see depends on which client they use, which operating system they’re on, and whether you’ve set up a fallback that looks good when the intended font isn’t available.

What email fonts actually are

There are two categories of fonts in email:

  • Web-safe fonts are fonts that come pre-installed on nearly every device and operating system. Examples include Arial, Helvetica, Georgia, Times New Roman, Verdana, and Courier. Because they’re already on the device, email clients can display them without downloading anything. They always work.
  • Web fonts are custom fonts that aren’t pre-installed. To display them, the email client has to download the font file from a font service (like Google Fonts) before rendering the text. Some clients support this; many don’t. Outlook, for example, generally does not. Gmail supports a limited set. Apple Mail supports them well.

The practical reality: when you use a web font, some readers will see it and some won’t. The ones who don’t will see your fallback font — the web-safe font you specify as a backup. If you don’t specify a fallback, the client picks one for you, and it’s usually not what you’d choose.

A fallback stack is the ordered list of fonts the client tries, one after another, until it finds one it can render. For example: Inter, Helvetica, Arial, sans-serif means “try Inter first; if that’s not available, try Helvetica; if that’s not available, try Arial; if none of those work, use the system’s default sans-serif font.”

Why it matters

  • Fonts carry brand identity. Your chosen typeface is part of how readers recognize your brand. When the font switches unexpectedly, the email feels generic or off-brand.
  • Readability changes with the font. Different fonts have different x-heights, letter spacing, and weights. A font swap can make text harder to read, especially at small sizes.
  • Layout can break. Fonts have different widths. If your fallback font is wider than your intended font, text may wrap differently, headings may push onto two lines, and the layout may shift.
  • The fallback is the reality for many readers. If a large portion of your audience uses Outlook (and many B2B audiences do), your fallback font is the font they actually see. It’s not a rare edge case — it’s the primary experience for a significant share of your list.

How to choose and set up email fonts

  1. Pick a web-safe font as your foundation. If you’re not sure where to start, choose a web-safe font for your body text. It guarantees consistency across every client and removes the font-swap problem entirely. Arial, Helvetica, and Georgia are safe, readable choices.
  2. If you use a web font, choose a visually similar fallback. The fallback should be the same category (sans-serif or serif), similar weight, and similar proportions. If your web font is a geometric sans-serif like Montserrat, a good fallback is Arial — not Georgia.
  3. Always specify a full fallback stack. Don’t stop at one fallback. List two or three web-safe options, then end with a generic family (sans-serif or serif) as the last resort.
  4. Don’t use web fonts for body text if Outlook matters to you. Web fonts are best for headings and short elements where a font swap is less disruptive. For long body text, a web-safe font keeps the reading experience consistent everywhere.
  5. Test the fallback. Send a test email to an Outlook account and look at it. That’s what many of your readers see. If the fallback looks bad, adjust it before sending.
  6. Set font sizes generously. Body text should be at least 14px, ideally 16px. Small font sizes that look fine in your intended font may become unreadable when the fallback font renders slightly differently.

Common mistakes

  • No fallback stack at all. The client picks its own fallback — usually something generic and unbranded.
  • Mismatched fallback. A sans-serif web font with a serif fallback (or vice versa) creates a jarring visual switch.
  • Web fonts for body text in B2B emails. If most of your audience uses Outlook, the web font never loads for them. You’ve designed around a font they never see.
  • Assuming the preview is universal. The builder shows the web font because the browser supports it. Outlook doesn’t. Preview is the best case, not the common case.

How to handle fonts in Temway

Temway gives you two layers of font control. First, workspace branding lets you set a default font family that applies to every email you build — so every email starts on-brand without you choosing a font each time. Second, custom fonts let you upload and use web fonts for headings and accents.

When you export the HTML, Temway generates a full fallback stack automatically — your chosen font first, followed by web-safe fallbacks in the same category. You don’t have to hand-write the stack or remember which fallback to use.

Preview your email in Desktop and Mobile to see the web font as most readers will. Then send a test copy to an Outlook inbox to see the fallback in action — the version many of your readers actually receive. When both look good, push it to your ESP for sending.

Where to go next