The way email shape-shifts across different clients has made many miserable—so much so that some have gone as far as building their own email clients just to avoid the quirks of Gmail and Microsoft Outlook that dismantle your Figma mockups. Others have condemned email clients to hell. And if you browse the threads on Quora, Reddit, or Stack Overflow, you don’t need to be an email guy to find out who the bad boy is in those discussions (read: rants).
Bottom line: Email clients test the limits of your patience like nothing else.
While the rise of frameworks such as MJML, and AI coding have offered developers some relief, compatibility still needs to be earned the hard way.
Why client compatibility is hard
The email client ecosystem is not a level playing field. Unlike web browsers, which have largely converged on modern standards, email clients operate on wildly different rendering philosophies.
As a result, email client compatibility is a perennial sticking point. For example:
- Outlook (Windows) uses Microsoft Word’s rendering engine, not a browser-based engine, which means it ignores many CSS properties like background-image, border-radius, flexbox, and CSS Grid entirely. Outlook 2007 through 2019 all share this limitation. It’s worth being precise here: this applies specifically to Outlook on Windows desktop. The Outlook mobile apps, webmail, and Outlook on Mac all have significantly better HTML rendering. So, the table-layout requirement really traces back to this one family of clients.
- CSS Grid and Flexbox remain unsupported. These are the cornerstones of modern web layout, but neither is reliably supported in Outlook or older mobile clients. Any template built around flex containers or grid columns will render as a single undifferentiated block of content in those environments.
- Background images in divs and sections are stripped by Outlook. A full-width hero section with a background image set via CSS will appear as a plain colored or completely blank box in Outlook clients. The workaround requires using Microsoft’s proprietary VML (Vector Markup Language) wrapped in conditional comments, a technique specific to Outlook.
- Absolute and relative CSS positioning breaks the layout structure. Unlike browsers, most email clients do not support CSS positioning in the way web developers expect. Elements placed with position: absolute can overlap, disappear, or reposition unpredictably.
- Gmail strips <head> styles in certain contexts, particularly when viewing emails through its web client, meaning any styles defined in a <style> block can be discarded.
In webmail clients, there’s an added layer: browser rendering on top of the client’s own interpretation. Gmail on Safari versus Gmail on Chrome will behave slightly differently, and no screenshot testing tool fully captures that.
There’s also dark mode, which complicates things. It inverts or adjusts colors in ways templates are never designed to handle. Not all clients render dark mode equally, either.
How ESPs disrupt HTML email compatibility
Client rendering is bad enough. But it isn’t the first roadblock.
Before your email reaches Gmail or Outlook, it passes through your email service provider — Mailchimp, Salesforce, Klaviyo, whatever you use — which may silently modify your HTML out of its own security or rendering concerns. The ESP might strip properties it doesn’t recognize, restructure your markup, or add wrapper elements that alter your layout. Testing against the final sent output, not just your local code, matters for exactly for this reason.
What makes an email compatible with clients
Creating a responsive and compatible email template involves many considerations.
But to begin with, these are the most fundamental things you need to get right before all else:
- Table-based layouts remain the most universally supported structural foundation for email templates. While <div> elements and CSS-based layouts are standard on the web, many email clients, particularly older versions of Outlook, don’t support them reliably. In that case, using nested HTML tables with explicit cellpadding, cellspacing, and width attributes written directly into the markup helps ensure a consistent structure.
- Inline styles are more reliable than external or embedded stylesheets. Since Gmail strips <head> styles entirely, the safest approach is to write CSS inline on every element.
- Images must always include alt text, explicit width and height attributes, and display: block.
- A single-column layout is the most resilient template. Single-column layouts with a maximum width around 600-700px maintain integrity across mobile, desktop, and web clients with minimal intervention.
- Custom web fonts are supported in Apple Mail and a handful of other clients, but in most email environments they will silently fall back to system fonts. A well-constructed font stack ensures that the typographic fallback is intentional and visually acceptable.
The role of conditional comments & defensive coding
Conditional comments are HTML directives that target specific clients, most commonly Outlook.
These use if mso syntax, directly analogous to the old if IE conditional comments web developers used during the Internet Explorer era.
- MSO conditional comments wrap Outlook-specific code in targeted blocks, such as providing VML background images or swapping out fluid div structures for rigid tables only where Outlook needs them.
- Ghost tables are a common defensive pattern where the table structure is wrapped in conditional comments specifically for Outlook This does involve some code repetition, but font styling and similar properties can live on the div alone since they’ll inherit correctly in Outlook.
- Hybrid coding techniques, sometimes called “spongy” or “fluid hybrid” design, develop emails that behave responsively even without media query support by using percentage-based widths on table cells combined with max-width constraints and mso-* CSS properties to control Outlook rendering separately.
A useful mental model here is progressive enhancement. You build something functional and accessible first, then layer improvements on top for capable clients. A missing border-radius in Outlook resulting in square corners is a graceful fallback, not a failure. Thus, the effort required to replicate rounded corners for that one client via images or VML is rarely worth it.
Accessibility in email
Luckily, accessibility in email overlaps significantly with web accessibility, but there are a few vital email-specific considerations worth knowing:
- Semantic elements work in email and should be used. Heading tags (h1-h6), paragraph tags, and list elements function correctly and provide structure for assistive technology.
- Add role=”presentation” to all layout tables. This tells assistive technology the table is being used for layout, not to represent data. It only needs to go on the <table> element itself, not on every tr and td. Most modern email clients respect this attribute, and screen reader technology is increasingly good at detecting display tables even without it.
- On the web, every page should have one <main>. In email, your code renders inside an email client that likely already contains a <main> in its own interface. Using one inside your email creates duplicate landmarks, which is an accessibility failure specific to email that a standard web audit wouldn’t catch.
- Font sizing is more variable than on the web. Default font sizes across email clients range from 12px to 17px, a much wider spread than in browsers. Apple Mail on desktop defaults to 12px if the user hasn’t changed their preferences, which is well below a comfortable reading size. The CSS max() function offers a practical path: font-size: max(16px, 1rem) renders at 16px if the system default is smaller, and respects the user’s preference if it’s larger.
Accessibility and broad compatibility are more connected than they might appear.
An email that’s properly semantically structured, has good contrast, uses alt text correctly, and is navigable with assistive technology will tend to degrade gracefully in restricted rendering environments almost as a side effect. The discipline of accessible markup enforces the same structural clarity that makes an email robust.
Tooling: You don’t have to hand-code everything
For developers new to email or marketing teams without a dedicated email specialist, frameworks can absorb a significant amount of the compatibility work. Two worth knowing:
- MJML: It is a markup language purpose-built for email. You write in a higher-level syntax and it compiles to the table-heavy, inline-styled HTML that email clients need. It handles a lot of the Outlook scaffolding automatically.
- Maizzle: Also a markup language, but it takes a different approach, letting you write email templates using Tailwind CSS and a Node.js build pipeline. It’s more flexible for developers comfortable with that ecosystem and has built-in support for things like inlining styles and targeting specific clients with CSS.
You can refer to our dedicated post on MJML and Maizzle for more information.
Testing for email client compatibility
Even the most carefully coded email can and will fail. Client rendering is an edge case on its own. No amount of theoretical knowledge replaces systematic cross-client testing before sending.
With that in mind, below are a few reminders on email testing:
- Email testing platforms like Litmus and Email on Acid render previews across 90+ client and device combinations. These platforms function similarly to BrowserStack for the browser world. You can send an email directly to a capture address or paste code in and get screenshots across all supported clients.
- Send test emails to real devices, particularly for dark mode and interactive elements, since rendered previews don’t always capture how clients apply dark mode transformations or handle hover effects. Free webmail signups cover a meaningful portion of real-world cases at no cost.
- Validate HTML with an email-specific validator. Email HTML is intentionally invalid by web standards — it uses deprecated attributes like bgcolor and align precisely because those work reliably in email where modern CSS doesn’t. Tools like Parcel (parcel.io) provide an email-specific code environment with an accessibility checker built for this context.
- Test with images disabled, which remains a default setting for many email clients, to verify that the email communicates its core message without relying solely on visuals.
Expert solutions for client compatibility—by Email Mavlers!
Email compatibility isn’t going away. If anything, the gap between what modern web development allows and what email clients tolerate continues to widen. Outlook will keep using its Word engine. Gmail will continue striping out the style tag. Dark mode will keep rewriting your colors. In other words, it’s par for the course in email marketing.
And we should know; we’ve been doing this for over 12 years now.
So if you’re looking to turn your perfect Figma mockups into fully functional, responsive, and client-compatible emails, we’re here to help. Let’s get started.