Fonts are a core part of email design, directly influencing readability, branding, and user experience. However, unlike websites where you can freely use any web font, emails are limited by varying client support. Some fonts may render perfectly in one inbox but get replaced or ignored in another. 

By understanding the limitations and applying fallbacks strategically, you can design emails that look clean, branded, and professional across all inboxes.

Here’s a detailed guide to understanding how fonts work in email development—and how to use them effectively.

Web-Safe Fonts (Best Choice)

Web-safe fonts are fonts that are pre-installed on most operating systems, including Windows, macOS, iOS, Android, and Linux. Since these fonts already exist on users’ devices, email clients can easily display them without needing to load anything externally.

Why they’re ideal for email:

• High compatibility: Supported by nearly all email clients, including Gmail, Outlook, Yahoo, and Apple Mail.
• No loading issues: No need for external requests or @font-face rules.
• Consistent rendering: Ensures your text looks as close as possible to your original design.

Common web-safe fonts include:

Tip: Arial and Helvetica are considered neutral and professional, making them suitable for most industries.

Custom Fonts (Difficult)

Custom fonts include fonts like Proxima Nova, Lato, Montserrat, or any Google Fonts, Adobe Fonts or self-hosted typefaces that are not pre-installed on devices. To use them in email, they are typically referenced via @font-face in <style> tag of the email or use a hosted service (like Google Fonts).

Why they can be difficult:

• Limited support: Most major email clients—especially Gmail, Outlook, and Yahoo—either strip out the custom font code or override it with a system default.
• Performance concerns: Even in supported clients, loading a custom font adds to the email size and could delay rendering.
• Visual inconsistency: If the fallback font looks very different, your layout might break or appear off-brand.

Clients that may support custom fonts:

• Apple Mail (macOS and iOS)
• Outlook for Mac
• Thunderbird
• Samsung Mail (partially)

Sometimes a custom font will appear to load because the font is already installed on the user’s device—not because the email client supports loading it.

Fallback Fonts

Because custom fonts can’t be trusted to render in every inbox, fallbacks are essential. A fallback font is used when the primary font fails to load. It ensures the email remains readable and visually close to the intended design.

Font stack example:

font-family: 'Proxima Nova', Arial, sans-serif;

In this case:

• 'Proxima Nova' is the preferred (custom) font.
• If not available, Arial (web-safe) is used.
• If Arial isn’t available, the browser will default to a generic sans-serif font.

Why use multiple fallback levels:

• To maintain your design's structure and readability across different platforms.
• To avoid layout shifts that can happen when a font’s metrics differ (e.g., line height, spacing).

Best practice: Always include at least one web-safe fallback after any custom font.

Font Support in Email Clients

Font support varies greatly between email clients. Here’s a simplified table showing how they behave:

* Fonts may render if already installed on the device.

** Gmail enforces Roboto (Android) and Helvetica (iOS).

*** Fonts often overridden or stripped completely.

***** Gmail applies aggressive font overrides, even for inline styles.

Examples of how fonts look in 3 most popular email clients - Apple Mail, Gmail and Outlook:

• Custom Font Kanit (https://fonts.google.com/specimen/Kanit):
  
  

• Web-safe font Arial:
  

Best Practices for Using Fonts in Email

Here are key rules every email developer should follow:

• Use web-safe fonts whenever possible.
• Always define fallback fonts – this ensures your message is readable and your branding is preserved as much as possible.
• Limit custom fonts to decorative purposes – such as logos in image form or minor stylized headings.
• Avoid relying on custom fonts for critical messaging – don’t use them for CTA buttons, navigation, or pricing.
• Test your emails across platforms – use tools like Litmus or Email on Acid to preview how your email renders in different clients.
• Optimize for legibility – regardless of the font, ensure your line height, font size, and contrast support readability.

Font Rendering in our editors

Classic Editor:

The preview area shows your brand font if it's defined. However, the editing mode displays only fallback fonts (e.g., Arial).

Our new editor provides a more advanced preview:

Tip: What you see in the email editor is not always what your subscribers will see. Always test live versions.