Why HTML Emails Still Break in 2026: The Rendering Problem Behind Gmail, Outlook and Apple Mail

Email doesn't have one rendering engine

A website is rendered by a browser engine — Chromium's Blink, WebKit, Gecko. Whichever one it is, there's basically one answer to "will this render correctly."

Email doesn't work that way. When you send an HTML email, the recipient's client decides how to interpret it, and that decision changes depending on where the email is opened. So there isn't one answer to "will this render correctly." The real question is: will it render correctly in the clients your recipients actually use?

That question is the whole job.

Outlook is the clearest example

"Outlook" doesn't mean one rendering engine, which is exactly what makes it confusing. Classic Outlook for Windows — the 2007 through 2021 desktop versions — has always rendered HTML email using the Microsoft Word engine. Not a browser. Word. The new Outlook for Windows, which Microsoft has been rolling out since 2024, is built on Edge WebView2 — an actual Chromium engine — and renders much closer to how Chrome does.

Microsoft has said it plans to retire the Word-based client around October 2026. That's close, but "planned end of support" isn't the same as "everyone has switched" — classic Outlook is still installed on a lot of machines, and will be for a while past that date. Which means both engines are live in your audience right now, and you still have to code for the older one. We went deep on exactly what changed and how to handle the transition in classic vs new Outlook rendering — worth a read if Outlook is more than a rounding error in your subscriber list. For the Gmail side of this comparison, see Gmail vs Outlook rendering differences.

Why Classic Outlook forced everyone into tables

On the modern web you'd reach for flexbox or grid. In email, tables remain the layout tool, specifically because the Word engine's CSS support splits along element lines: width, height and padding behave far more reliably on <table> and <td> than on a generic <div>.

So instead of this:

<div class="container">
  <div class="column">Content</div>
</div>

email developers write this:

<table role="presentation" width="600">
  <tr><td>Content</td></tr>
</table>

Not because anyone forgot how modern CSS works. Because reliable email HTML gets written around the capabilities of the least capable client you still need to support.

Even "margin: 0 auto" isn't safe

Here's a small one that catches people off guard. On the web you'd center a block with:

margin: 0 auto;

Outlook's Word engine doesn't honor the auto value on margin — it's a documented bug, not a rumor, and it's been true across every desktop Outlook version from 2007 through 2019. That's the actual reason <table align="center"> still shows up in production email code. It isn't an old habit nobody bothered to update. It's the only mechanism that engine reliably respects.

It's a useful example of the pattern that repeats through all of email development: when a modern CSS technique isn't reliable enough, you fall back to the older HTML mechanism the client actually handles.

MSO conditional comments: two versions of the same email

Classic Outlook supports Microsoft's own conditional-comment syntax:

<!--[if mso]>
  Outlook-specific HTML goes here
<![endif]-->

The idea is simple — give Outlook one version of the markup and let everyone else use another. A normal <div>-based section can sit right next to an Outlook-only <table> wrapped in that conditional, and nothing about it is a hack. It's a deliberate compatibility layer, and classic Outlook still honors it.

mso-* properties and VML

Outlook's Word engine also reads its own proprietary CSS, prefixed mso-. A production email routinely carries both a real declaration and Outlook's version of it, side by side:

padding: 12px 20px;
mso-padding-alt: 12px 20px;

Fonts get the same treatment. Outlook drops any @font-face declaration and falls back straight to Times New Roman unless you also set mso-font-alt and mso-generic-font-family — which is one more reason a solid fallback stack matters more in email than it ever does on the web. We go deeper on font handling across clients in the email-safe fonts guide.

Then there's VML — Vector Markup Language, a Microsoft technology from the late 1990s. Classic Outlook still uses it for effects CSS can't reliably deliver there: background images via VML's fill element, and rounded corners via its RoundRect element, since neither background-image nor border-radius work in the Word engine on their own. Both live inside an [if mso] conditional so every other client just ignores them.

None of this is decorative complexity. Each piece exists because one specific engine can't do the modern equivalent.

Images need attributes, not just CSS

A browser developer reaches for CSS to size an image:

<img src="image.jpg" style="width:80px; max-width:80px;">

Email developers add the HTML width and height attributes on top, for good reason: percentage widths on <img> can resolve against the physical file's dimensions rather than the parent element, and attribute-based sizing doesn't always scale correctly at higher DPI settings. Belt and suspenders:

<img
  src="image.jpg"
  width="80" height="80"
  style="width:80px; height:80px; max-width:80px;"
  alt="Example"
>

The more engines you need to support, the less you want to depend on one interpretation of CSS alone.

Dark mode is its own compatibility layer now

Modern clients transform your colors for dark mode, and they don't all do it the same way — some rewrite your @media (prefers-color-scheme: dark) rules, some ignore them and repaint your colors anyway, some inject their own data attributes to track what they changed. Light-mode rendering doesn't tell you anything about what happens to your logo, your borders, or your "white background with dark text" button once a client decides to invert it.

We've reverse-engineered exactly how this happens on the Gmail side in how Gmail rewrites your email colors in dark mode, and covered Apple Mail's version of the same problem in Apple Mail dark mode preview. If your email needs to hold up in dark mode, checking it in light mode only tells you half the story.

"It looks fine in my browser" means almost nothing

This is the lesson that costs people the most time. If you open your HTML in Chrome and it looks perfect, you've verified exactly one thing: Chrome can render your HTML. You haven't verified Gmail, Outlook, Apple Mail, Yahoo, mobile clients, dark mode, or either version of Outlook.

Your browser is not an email client. And your email client is not necessarily your recipient's email client. That's the entire reason email testing is a different exercise from checking a page in one browser — MailViewr's preview tool exists specifically to close that gap: paste or upload your HTML and see it rendered the way Gmail, Outlook, Apple Mail and mobile clients actually render it, side by side, with the unsupported CSS flagged for you. Five previews are free before you need an account.

There is no one "correct" way to code an email

There's only the best implementation for the clients your recipients actually use. A one-off internal email to five coworkers has a very different bar than a campaign going to a list that's half Gmail, a third Outlook, and the rest everything else. The right question was never "what's the correct HTML email markup" — it's "which clients does my audience use, and what does this look like in each one." That question is also most of what our HTML email best practices guide and the ultimate guide to HTML email testing are built to answer.

The actual workflow

Reliable email development isn't build → open in browser → send. It's closer to:

If you're starting from a blank page rather than debugging an existing template, our free drag-and-drop email builder already writes the tables, inline CSS, and Outlook fallbacks for you — so you're not hand-typing MSO conditionals from a blog post at 11pm before a send.

The strange technology is the solution, not the problem

Tables, MSO conditionals, mso-* properties, VML — all of it looks ridiculous coming from modern frontend work. But each piece is a direct answer to a fragmented rendering environment. Tables exist because some clients handle them more reliably than divs. Conditional comments exist because Outlook needs different markup than everyone else. mso-* properties exist because Outlook has its own rendering rules. VML exists because the Word engine needs a different way to draw a background or a rounded corner. Fallback fonts exist because fonts aren't universal. Explicit image dimensions exist because CSS isn't interpreted the same way everywhere.

And testing exists because you cannot infer the final render from the source code alone.

HTML email isn't broken. It's fragmented.

That's the more useful way to hold this. It isn't an outdated version of web development — it's a different environment with different constraints, and those constraints are still shifting. The Outlook engine split we covered above is a live example: Microsoft is actually retiring the twenty-year-old Word engine, on a timeline that's now measured in months, not years. The compatibility problem hasn't gone away. It's gotten more specific — you now have to think about which client, which platform, and sometimes which version.

If any of this sounds familiar because you're the frontend developer who got handed an email task with no context and no budget for real testing tools, we wrote about that exact situation in "You know HTML, right?".

Build for the email, not just the HTML

The best HTML email isn't the one with the most modern code. It's the one that renders the way you intended for the people who actually open it. Build it with the techniques the clients you support can handle. Preview it across those clients before you trust it. Validate the things a quick glance won't catch. Fix what you find. Ship only once you know what your recipients will actually see.

Because in HTML email, the source code is only half the story. The rendering is the other half.