Skip to main content

Email Compatibility Checker

What it does

The Email Compatibility Checker scans pasted HTML email source for CSS features and structural patterns that don’t work consistently across email clients. The output identifies each issue with the specific clients that will break (Outlook 2007-2019, Gmail apps, Apple Mail, Yahoo Mail) and suggests a workaround in plain language. Saves the surprise of building an email that looks great in your preview but renders broken in subscribers’ Outlook inboxes.

Common situations

You’ve designed a beautiful email using modern CSS (flexbox, grid, gradients, web fonts) and want to know whether it’ll render correctly across clients before sending. The checker reveals the gap — usually flexbox doesn’t work in Outlook, gradients are stripped in older clients, and web fonts fall back to defaults in some places.

A subscriber complains that your email looks broken on their device. They mention “Outlook” — which gives you the clue, but you need to know specifically what’s breaking. The checker flags the specific features in your email that Outlook doesn’t support, narrowing the diagnosis.

You’re handing email templates over to a client and want to certify they’ll render correctly across their audience’s email clients. Run each template through the checker; document the compatibility issues so the client knows what to expect.

You’re moving from one email service to another and want to verify your existing templates still work. Sometimes templates that worked at one ESP fail at another due to different rendering pipelines (some inline more aggressively, some preserve more CSS). The checker catches gaps before they hit subscribers.

You’ve inherited an old email template that “works fine” but you’re suspicious. Old templates often use outdated patterns that work in some clients and silently break in others — the checker reveals what specifically would cause issues.

What you need to know

Email clients support far less CSS than modern browsers. The reason: most email clients prioritise security and consistency over feature richness, and Microsoft Outlook for Windows uses Microsoft Word as its rendering engine — which means many modern CSS features that have been browser-supported for a decade simply don’t work there.

The major clients and their quirks:

Outlook for Windows (2007-2019): uses Word for rendering. No CSS flexbox, no CSS grid, limited support for background images, no CSS variables, no :has() or :is() pseudo-classes. Tables are the only reliable layout primitive. This is the lowest-common-denominator client and what email developers traditionally code against.

Outlook 365 / web: more modern but still strips many CSS features. Slightly better than Outlook desktop but still not modern-browser-equivalent.

Apple Mail (macOS, iOS): among the best CSS support in email clients. Most modern features work but some pseudo-classes and very new features still fail.

Gmail (web, app): middle ground. Most modern CSS works but some quirks remain. Gmail strips <style> blocks in some clipping scenarios; inline styles are safer.

Yahoo Mail, AOL Mail: similar to Outlook in CSS conservatism. Tables for layout, inline styles for safety.

Mobile clients (Apple Mail iOS, Gmail iOS, Outlook iOS, Samsung Mail): typically better than desktop equivalents because mobile clients are newer codebases.

What the checker scans for:

  • CSS Flexbox (display: flex) — breaks in Outlook 2007-2019
  • CSS Grid (display: grid) — breaks in Outlook (all versions), Apple Mail in some configurations
  • Gradient backgrounds — Outlook ignores gradients entirely
  • CSS variables (var(--name)) — not supported in Outlook, Yahoo Mail
  • External stylesheets (<link rel="stylesheet">) — stripped by most clients
  • JavaScript (<script>) — stripped by every client
  • CSS positioning (position: absolute, position: fixed) — breaks in Outlook
  • CSS @media queries — supported in modern clients but inconsistent in older Outlook
  • Web fonts (@font-face, Google Fonts) — fall back to default in Outlook
  • Modern CSS pseudo-classes (:has(), :is(), :where()) — not supported in any email client reliably
  • Background images on body — strip in Outlook 2010+
  • Images without alt attributes — break image-blocked client experiences
  • Images without explicit dimensions — cause layout shifts in Outlook

The checker is built around the same compatibility data that powers caniemail.com — the canonical reference for “does this CSS work in this email client”. The checker covers the most common issues; for edge-case features, caniemail.com has the full database.

Frequently asked questions

Why is Outlook so different from other email clients?

Microsoft Outlook on Windows uses Microsoft Word as its rendering engine — Word is a document processor, not a browser. It doesn’t understand modern CSS the way browsers do. Outlook on Mac and Outlook 365 use different engines and are more modern, but Outlook desktop on Windows is the conservative baseline most email developers code against.

Should I use tables for email layout?

Yes — for cross-client safety, HTML tables remain the standard layout primitive. Div-based layout works in modern clients but breaks in Outlook desktop. Tables work everywhere. Email developers in 2026 still use the same patterns email developers used in 2010 because Outlook hasn’t moved.

Are inline styles required?

Highly recommended. Some clients (Gmail in some clipping scenarios, AOL) strip <style> blocks. Inline styles always work. Most email service providers offer “CSS inlining” automatically — they parse your <style> block and inline the rules onto each element before sending.

Do CSS animations work in email?

In Apple Mail: yes. In modern Gmail: partially. In Outlook: no. Email developers occasionally use animations as progressive enhancement — the static fallback works everywhere, the animation works for the audience that supports it. Don’t rely on animation for content delivery.

What about dark mode?

Apple Mail and most modern clients support dark mode in email. The CSS for it is @media (prefers-color-scheme: dark). The challenge is that some clients invert colours automatically (Outlook for example), which can produce unexpected results. Dark-mode-tested templates are non-trivial; if dark mode matters, test in Litmus.

Why doesn’t the checker render the email?

Rendering an email faithfully across the major clients requires running them in actual mail-receiving environments — that’s what Litmus and Email on Acid pay for, and it’s expensive. The checker uses pattern detection on the source instead — fast, free, and catches the structural issues that cause most rendering breaks.

Should I avoid modern CSS entirely?

No — use it as progressive enhancement. Build for Outlook with tables and inline styles, then layer modern CSS for clients that support it. Pages that look basic in Outlook and beautiful in Apple Mail are the working pattern.

What about using framework-generated email templates?

Most email frameworks (MJML, Maizzle, Foundation for Emails) handle the cross-client compatibility for you. They produce table-based output with inline styles by default. The checker still works on their output to verify nothing custom you’ve added breaks the compatibility.

Common problems

Problem: Email looks great in Apple Mail and Gmail, broken in Outlook.

Common pattern: the email uses modern CSS (flexbox, grid) that works in modern clients but Outlook ignores. The checker should flag the specific CSS features. Replace with table-based layout for the affected sections; modern CSS still works in clients that support it via progressive enhancement.

Problem: Email looks fine in checker but broken in actual Outlook.

The checker covers the most common issues but not every Outlook quirk. For comprehensive Outlook testing, Litmus or Email on Acid render the email in actual Outlook environments. The checker is a fast pre-flight; Litmus is the comprehensive review.

Problem: Background image renders in Apple Mail but not Outlook.

Outlook on Windows ignores background-image on most elements. Workarounds: use VML fallback for Outlook (specific Outlook-only markup), or use a regular <img> with positioning, or accept Outlook users see solid colour. VML is the cross-Outlook solution but adds complexity.

Problem: Web font is showing fallback in some clients.

Web fonts (Google Fonts, custom @font-face) work in Apple Mail, modern Gmail, and most modern clients, but fall back to defaults in Outlook (all versions) and some Gmail apps. Always include a fallback in the font-family declaration: font-family: 'Custom Font', Arial, sans-serif. The custom font shows where supported; Arial-equivalent shows everywhere else.

Problem: CSS classes don’t apply in some clients.

Classes work in clients that preserve <style> blocks. Some clients strip them; in those cases, only inline styles work. Use a CSS inliner (most ESPs include this; Foundation for Emails has one as a build step) to inline styles before sending.

Tips

  • Use tables for layout, inline styles for safety. Yes, like 2010. It’s still the working pattern.
  • Always test in actual Outlook before launching important campaigns. Litmus, Email on Acid, or even a Windows VM with Outlook installed.
  • Set width and height on every image. Outlook needs them to reserve space.
  • Always include alt text. Image-blocked clients (which include Outlook by default) show alt text instead.
  • Don’t use CSS shorthand for backgrounds in inline styles. Some clients only parse certain shorthand patterns. Use long-form for safety.

Related tools in this suite

The Inbox Reachability Checker covers the full email including content and authentication; this tool focuses specifically on rendering compatibility. The Plain Text Generator creates the alternate format some clients fall back to.

What this looks like at scale

For a single email, the checker is the right pre-launch verification. For organisations sending many emails using templates, compatibility should be enforced at the template level — templates built once on table+inline patterns, then content slotted in without breaking the structure. Most modern email frameworks (MJML, Foundation, Maizzle) handle this; for hand-rolled emails, the checker is the safety net.

Take it further

If your email program has chronic rendering issues across many templates, the structural fix is usually template consolidation onto a framework like MJML. Talk through the situation and we can scope what migration looks like.