Email Rendering Across 90+ Clients: The Definitive Guide

The Email Client Landscape in 2025

There are over 90 distinct email client/rendering engine combinations in active use today. Unlike web browsers, which have largely converged on the same rendering standards (thanks to Chromium’s dominance), email clients use wildly different engines. Apple Mail uses WebKit. Gmail uses its own proprietary rendering pipeline that strips external styles and rewrites class names. Outlook on Windows uses Microsoft Word’s HTML renderer—yes, the word processor. Outlook on Mac uses WebKit. The Samsung Email app has its own quirks. And that is before you account for the dozens of smaller webmail clients, corporate email gateways, and accessibility readers.

The result is that an email that looks perfect in Apple Mail can be completely broken in Outlook. A responsive layout that stacks beautifully on iPhone may render as a horizontal scrolling mess in Gmail’s Android app. This guide covers the most impactful rendering differences and gives you strategies to handle them.

Outlook: The Word Rendering Engine Problem

Outlook on Windows (2007 through the current desktop version) uses Microsoft Word’s rendering engine for HTML email. This means huge portions of CSS simply do not work: no float, no position, no max-width on block elements, no background-image on divs, no border-radius on most elements, no margin: auto for centering. If you have only tested in web-based clients, Outlook is where your email goes to die.

<!-- Conditional comments for Outlook-specific code -->
<!--[if mso]>
<table role="presentation" width="600" cellspacing="0" cellpadding="0" border="0" align="center">
<tr><td>
<![endif]-->

<div style="max-width:600px; margin:0 auto;">
  <!-- Your responsive content -->
</div>

<!--[if mso]>
</td></tr></table>
<![endif]-->

The pattern above is called a “ghost table.” The <div> handles modern clients that support max-width, while the conditional table provides a fixed-width container for Outlook. You will use this pattern constantly in email development.

Outlook-Specific CSS Issues

Line-height: Outlook often adds extra spacing to text. Use mso-line-height-rule: exactly; alongside your line-height declaration. Padding: Outlook inconsistently applies padding to table cells. When in doubt, use nested tables instead of padding for spacing. Images: Outlook may add gaps below images. Always add display: block; and explicit width/height attributes to every <img> tag.

Gmail: Style Stripping and Class Rewriting

Gmail’s web client strips <style> blocks from emails that do not meet certain criteria (such as being larger than 102KB). Even when embedded styles are preserved, Gmail rewrites all class names by prefixing them, so your CSS class selectors may not match. Gmail also does not support the :hover pseudo-class, @font-face, or many CSS animations.

The practical implications: always inline your critical styles. Use embedded <style> blocks only for progressive enhancement (responsive media queries, dark mode support). Never rely solely on class-based styling. Gmail on mobile (both Android and iOS) has better CSS support than Gmail web, but test both.

<!-- Gmail-safe pattern: inline styles + embedded for enhancement -->
<style>
  /* These will be stripped by Gmail web if email > 102KB */
  /* But work in Gmail mobile, Apple Mail, etc. */
  @media only screen and (max-width: 600px) {
    .mobile-full { width: 100% !important; }
    .mobile-hide { display: none !important; }
  }
</style>

<!-- Critical styles are always inline -->
<table style="width:600px; background-color:#ffffff;" class="mobile-full">
  <!-- Content -->
</table>

Apple Mail: The Best-Case Scenario

Apple Mail (on macOS and iOS) is the most capable email rendering engine. It uses WebKit, supports modern CSS including animations, media queries, flexbox (to some extent), web fonts, SVG, and even <video> elements. If every email client rendered like Apple Mail, email development would be trivial.

However, Apple Mail’s capability is a double-edged sword: if you only test in Apple Mail, you will build emails that look incredible in one client and break everywhere else. Use Apple Mail as your “aspirational” rendering target—progressive enhancements that take advantage of its capabilities—while ensuring your baseline HTML/CSS works in Outlook and Gmail.

Progressive Enhancement Strategy

Build your email in three layers: (1) a table-based, inline-styled baseline that works in Outlook and Gmail, (2) embedded CSS with media queries for responsive behavior in clients that support <style> blocks, and (3) advanced features (web fonts, animations, interactivity) for WebKit-based clients like Apple Mail. This layered approach ensures every recipient gets a functional email while advanced clients get a richer experience.

Mobile Rendering Considerations

More than 60% of emails are now opened on mobile devices. Mobile email clients introduce their own set of challenges. The iOS Mail app and Android default mail apps generally render well, but third-party apps like Spark, Edison Mail, and corporate MDM clients can introduce unexpected behavior.

Key mobile considerations: Touch targets: Buttons and links should be at least 44x44 pixels for comfortable tapping. Font size: iOS auto-scales text smaller than 13px, which can break carefully designed layouts. Use -webkit-text-size-adjust: 100%; to prevent this. Image scaling: Use max-width: 100%; on images so they do not overflow the viewport. Preheader text: Mobile clients show 40–90 characters of preheader text in the inbox list—optimize this for mobile-first since it is where most of your opens happen.

Testing Strategies and Tools

You cannot test email rendering by sending test emails to your personal accounts. You need systematic cross-client testing. The three main approaches are:

Screenshot-based testing services: Litmus and Email on Acid render your email across 90+ client configurations and provide screenshots. This is the gold standard for pre-send testing. Litmus offers real-time previews and a code editor; Email on Acid is more affordable for smaller teams.

ESP-integrated previews: Brew includes cross-client preview rendering directly in its template editor, so you can see how your email looks across clients without leaving the tool. This tight integration means you catch issues during development rather than after deployment.

Manual testing on real devices: Keep a small device lab (or use BrowserStack for email) to test on actual devices. Automated screenshots catch most issues, but some rendering behaviors (animations, interactive elements, dark mode transitions) can only be properly evaluated on real hardware.

// Automated rendering test in CI with Litmus API
const response = await fetch("https://api.litmus.com/v1/tests", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.LITMUS_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    html: renderedEmailHtml,
    clients: ["ol2019", "gmail", "iphone15", "android10", "applemailmacos"],
  }),
});

const test = await response.json();
console.log(`Preview URL: ${test.preview_url}`);

A Practical Testing Checklist

Before sending any email to production, verify these critical rendering points: Outlook desktop: Does the layout hold with tables? Are images sized correctly? Do buttons display? Gmail web: Does the email look acceptable without <style> blocks (inline-only)? Is the content under 102KB? Apple Mail: Does the responsive design collapse properly? Do enhanced features degrade gracefully? Mobile (iOS and Android): Are touch targets large enough? Is text readable without zooming? Do images scale? Dark mode: Is text readable on dark backgrounds? Do your colors have sufficient contrast in both modes?

Automate as much of this checklist as possible. Integrate Litmus, Email on Acid, or Brew’s preview API into your CI pipeline so that every template change is tested before it reaches production. The cost of a rendering bug in email is not a quick hotfix—once an email is sent, you cannot update it in the recipient’s inbox.