Which web font formats work in email?

Only embedded TTF and OTF fonts with Base64 encoding in inline CSS are reliably supported in modern email clients like Apple Mail and Gmail.

Why don’t Gmail and Outlook support web fonts?

Both clients block external resources and strip embedded fonts for security and performance reasons. Outlook, in particular, relies on system fonts only.

Can I use Google Fonts in emails?

No. Google Fonts and similar CDN-based fonts use tags or external CSS, which are blocked by all major email clients.

Is it safe to embed fonts in email using Base64?

Yes, when done with TTF or OTF formats and properly coded with inline styles. It works in Apple Mail and Gmail but not Outlook.

What should I use as a fallback font in emails?

Always include a comma-separated list of common system fonts like 'Helvetica, Arial, sans-serif' to ensure readability.

How can I test if my email's fonts will render correctly?

Use inbox placement testing tools to simulate rendering across Apple Mail, Gmail, Outlook, Samsung Mail, and others.

Does using custom fonts affect spam filters?

No directly. But poor rendering can lead to user complaints, which hurt sender reputation and indirectly affect deliverability.

Can I use WOFF2 in email?

No, WOFF2 is not supported in any email client. It is intended for web browsers only.

What’s the best way to ensure email consistency across devices?

Design with system fonts only. If you must use custom fonts, embed only TTF/OTF via Base64 and test across clients.

Does MailTester help with email rendering issues?

Yes. Our inbox placement testing shows how your email renders in real client environments, including font and layout behavior.

Should I avoid any font styles in email?

Avoid using non-system fonts unless absolutely needed. Script and decorative fonts have no fallback and will fail to render.

What are the most common font-related issues in email?

Font fallbacks, missing typefaces, and inconsistent text appearance across devices. These degrade branding and user experience.

Web Font Formats for Email

Why do web fonts in emails often fail to render?

You’re sending a beautifully designed email. The fonts are perfect—on your screen, in your inbox tester, even on mobile previews. Then it lands in a recipient’s inbox. And suddenly, it’s all Times New Roman and Arial.

That’s not a design flaw. It’s the reality of email clients: they strip or ignore modern web font formats like WOFF2 and WOFF. Only a few clients support embedded fonts at all—and even then, inconsistently. The result? Your carefully chosen custom font vanishes, replaced by system defaults. Brand identity falters. Design consistency collapses.

Why? Because email clients prioritize security, rendering speed, and compatibility over typographic ambition. The formats you use for websites—WOFF, WOFF2, SVG—are often blocked or ignored. Even if a client supports embedded fonts, it may still fall back to a system font, leaving you with zero control over the final render.

Compatibility isn’t just a nice-to-have—it’s essential. If your email uses a web font format not supported by the majority of email clients, it won’t render as intended. That’s why choosing the right compatible web font formats for maximum email client support isn’t optional. It’s the foundation.

Key takeaways

Only a few email clients (like Apple Mail and modern Outlook for macOS) support embedded fonts, and support varies widely.
WOFF2 and WOFF are commonly rejected by email clients due to security restrictions and rendering limitations.
The only reliably supported web font formats for emails are embedded base64-encoded versions of TrueType (TTF) and OpenType (OTF) fonts, delivered via inline CSS.

What are the only web font formats reliably supported in email?

Only OpenType (OTF) and TrueType (TTF) fonts are reliably supported across major email clients. While Embedded OpenType (EOT) was once used for older Outlook versions, it’s now obsolete. Base64-encoded fonts in inline CSS can work in Apple Mail and Gmail—but only if served with the proper Content-Type, like application/x-font-otf or application/x-font-ttf. Always test with tools that check deliverability across clients.

Legacy formats won’t cut it anymore

Older Outlook clients (like Outlook 2007–2013) did support EOT, but that’s a relic of the past. Modern email apps no longer recognize it, and attempting to use it only adds unnecessary bloat. If you’re still seeing EOT in legacy code, it’s time to retire it.

OTF and TTF: your best bet for reliability

OpenType (OTF) and TrueType (TTF) are the only formats consistently rendered across Gmail, Apple Mail, Outlook on the web, and iOS Mail. These formats are widely supported because they’re standardized, lightweight, and well-documented. Use OTF when you need advanced typographic features, or TTF for maximum compatibility.

However, even with OTF/TTF, you can’t assume success without testing. Rendering can vary by client, especially if fonts aren’t embedded correctly. For instance, some clients may fall back to system fonts if the embedding fails. That’s where inbox placement testing matters.

Want to check how your email appears across real client environments? Run a test with real inbox tests across popular clients—before you send.

Base64 embedding: possible, but fragile

Some newer clients allow base64-encoded fonts in style blocks via inline CSS. Gmail and Apple Mail may display them correctly if the MIME type is set properly. But if the Content-Type header is missing or wrong, the font fails silently, and the email reverts to fallbacks.

For example, a font served as text/plain will not load—even if base64 is intact. You must use application/x-font-otf or application/x-font-ttf in your MIME configuration. This is not common practice outside of well-structured email templates, so test thoroughly.

To learn more about how email clients handle fonts, refer to the W3C CSS Fonts specification. While it doesn’t cover email-specific quirks, it defines the standards that most modern clients attempt to follow. For reliable results, stick to OTF and TTF when possible, and avoid assuming any format works universally.

Which email clients support custom fonts, and how?

You can embed TTF and OTF fonts in email via Base64-encoded

Compatible Web Font Formats for Maximum Email Client Support