Classic Outlook vs the new Outlook: what's actually changing

You spend an hour polishing an email, and it looks perfect everywhere, until someone opens it in Outlook and the rounded corners disappear, or the background image simply never loads. It's one of the oldest headaches in email development, and it's still very much alive.

Outlook renders emails differently depending on which version your recipient uses, and the gap between the two is bigger than most conversations about it let on. Classic Outlook uses Microsoft Word's rendering engine. New Outlook uses a browser-based engine instead. That single difference explains most of the rendering quirks email builders have worked around for years. At RGE Studio, we track these changes closely because they directly affect the emails our customers send. Here's what's actually happening, in plain terms, and what it means if you build or send an email.

First, the basics: why are there two Outlooks?

Outlook isn't one single piece of software anymore. There's classic Outlook, the version most companies have used for years, and there's a new Outlook, which Microsoft has been rolling out gradually since 2022.

The difference that matters most is invisible to the average user but huge for anyone coding an email: classic Outlook doesn't display HTML the way a browser does. It uses Microsoft Word's rendering engine instead, a decision Microsoft made decades ago that never changed for this version. Word was never built to interpret web pages, so it handles things like background images, rounded corners, and font fallbacks in its own, Idiosyncratic way.

New Outlook drops that constraint. It's built on the same browser-based engine as Outlook.com, so it renders much closer to how Chrome or Safari would. Huzzah.

A rollout that's taken, and will keep taking, years

Microsoft first announced its "One Outlook" vision in January 2021, a single web-based client meant to eventually replace the separate desktop apps. The rollout since then has moved in stages, not all at once:

• May 2022: the new client, internally codenamed Monarch, appeared in beta, essentially Outlook's web version wrapped in Edge WebView2
• April 2023: available to everyone through the Windows App Store, via the "Try the new Outlook" toggle
• September 2023: general availability for personal accounts. Mail & Calendar app users began migrating automatically; the older apps were retired at the end of 2024
• August 2024: general availability for commercial accounts, still opt-in
• January 2025: Business Standard and Premium tenants started moving to the new client by default, with an opt-out still available

Enterprise accounts are on the slowest timeline of all. Microsoft originally targeted an opt-out stage for April 2026 and has since pushed it back to May 2027, though that date isn't officially confirmed and could shift again. Classic Outlook is expected to remain on Microsoft's support roadmap at least through 2029, though Microsoft hasn't published an official end date.

The new engine has technically existed since 2022, but classic Outlook isn't going anywhere in real inboxes any time soon. If your list skews toward large companies, the accounts most likely to be running classic Outlook are exactly the ones scheduled to move last. For the next several years, expect both versions to keep showing up in the same inbox, sometimes even on the same team.

What actually changes between the two

Here's a practical comparison of the issues email teams are most likely to encounter.

A couple of these deserve a bit more context than the table alone gives you.

The max-width row is really about table-based markup becoming the email coding standard in the first place. Classic Outlook ignores positioning, floats, and widths on divs entirely, so a responsive layout means wrapping fixed-width tables and ghost tables inside conditional comments just to hold their shape. The technique even has its own name, fluid-hybrid coding. If you're using a builder that generates table-based HTML by default, you've already sidestepped this without knowing it, since there's nothing left to hand-code after the fact.

The phantom white lines row is worth a mention too, mostly because it's such a strange bug to run into cold. Odd pixel heights on table cells can produce random white lines with no obvious cause, and the fix, even pixel values plus border-collapse, isn't something you'd guess on your own the first time it happens.

Why "better" still doesn't mean "solved"

New Outlook renders like Outlook.com, and Outlook.com has its own quirks, including only partial support for media queries, so edge cases still show up. It's a real improvement, just not a perfect stand-in for a browser. Microsoft itself has even admitted that table alignment and column widths can still render differently between new and classic Outlook, and that's Microsoft saying it, not a third party. So if you're sending anything visually precise, side-by-side testing across both versions still earns its keep, and will keep earning it for as long as both are active in real inboxes, which, based on the enterprise timeline above, is likely to be years yet.

You still can't design for one engine and call it done. Dual-engine coding, writing HTML that accounts for both classic and new Outlook at once, will remain necessary through at least 2027. Conditional comments make that possible: each engine ignores the workarounds intended for the other, so a well-coded email degrades gracefully in either engine instead of requiring two separate versions. The one caveat is not to overdo it, since too many conditional comments bloat the file size, which is often the real cause of clipping in Gmail, trading one rendering problem for another.

What this means for the code RGE Studio generates

Every row in that table is a decision RGE Studio's HTML output has to make correctly, without you having to think about it.

A brief history of RGE Studio's HTML

RGE Studio's HTML for Email has gone through three major iterations since 2014:

• Version 1 (2014–2017): table-based, built around a fluid-hybrid design for mobile responsiveness, but it produced large files that caused clipping issues in Gmail and Yahoo
• Version 2 (2017–2022): moved to a div-based structure inspired by Rémi Parmentier's Fab Four technique, achieving responsiveness without media queries and cutting the file footprint
• Version 3 (2022–today): our current approach, combining table-based layout with conditional comments used only where they're actually needed, which is what keeps files lean while still holding up in classic Outlook

What RGE Studio handles automatically

• VML fallbacks, applied automatically. Rounded corners and background images, the elements that need VML to survive classic Outlook, get it without your hand-coding roundrect workarounds
• Table-based layout by default. Classic Outlook doesn't reliably support div-based structure, so tables stay the foundation. This is also why multi-column layouts hold up instead of collapsing to single column, which is the workaround a lot of tools quietly fall back on
• Explicit image dimensions. RGE Studio includes the HTML width and height values classic Outlook expects, helping prevent high-resolution images from rendering at their native size
• HTML minification on export. Business and Enterprise accounts can toggle minification when exporting, so file size doesn't creep up as designs get more complex. This matters because bloated files are often the real cause of clipping in Gmail rather than Outlook itself

New Outlook fixes a genuinely long list of real problems, but classic Outlook isn't going anywhere on any timeline you can plan a campaign around. Until it does, the code has to hold up in both worlds at once, invisibly, so you don't have to think about which Outlook your subscriber happens to be running.

If you're curious how this plays out in an actual builder rather than just in principle, our Help Center article on how RGE Studio handles Outlook rendering has the full breakdown.

‍