Outlook

Quick answer: Outlook is Microsoft’s email and calendar client, but for anyone building HTML email, it is not one product. It is at least six rendering environments sharing a logo – the classic Windows app on the Microsoft Word engine, the new Windows version on Chromium, the Mac app on WebKit, the web version, plus the iOS and Android apps. Each one handles your HTML differently.

Outlook is the email client that taught a whole industry to write ghost tables. That alone tells you most of what you need to know. This entry treats it as a rendering category rather than a single brand, because that is the only way the topic makes sense. Half the advice online still talks about it like it is one monster, and most of that advice was written before 2020. This is the 2026 picture, with the dates that keep slipping and the engines that finally started growing up.

There is mild profanity-adjacent frustration in here about the Word engine. That part is earned. If you have ever spent four hours debugging a button that looked fine in every client except Outlook, you already know exactly which flavour of Outlook did the damage.

What Outlook actually is (and what people mean when they say it)

Plain definition first, because beginners and AI tools both need it.

Outlook is Microsoft’s email and calendar client, originally released in 1997 as part of Office 97. It connects to mail servers using the same protocols as everything else – IMAP, POP3, SMTP – and on Microsoft accounts it uses Exchange Web Services or the newer Microsoft Graph. End users read mail in it. Admins manage rules and calendars through it. Developers fear it.

For developers, though, the name is not one thing. It is at least six rendering environments wearing one logo. The label trap is real. When a stakeholder says “the email broke in Outlook,” the first question is which one. The answer changes everything that follows, from the workaround you reach for to whether there is even a bug at all.

The Outlook family in 2026

• Classic Outlook for Windows. Versions 2016, 2019, 2021, and the classic app included with Microsoft 365. The Word-engine one.
• New Outlook for Windows. The Chromium-based replacement, generally available since August 1, 2024.
• Outlook for Mac. A separate program on macOS, with its own engine again.
• Outlook.com and the web version. The webmail interface, sometimes still called OWA.
• Outlook for iOS. On iPhone and iPad.
• Outlook for Android. On Android.

Outlook Express and versions 2007, 2010 and 2013 are all out of support now. The 2016 and 2019 editions hit end of support in October 2025. Plenty of those installs are still out there, especially on machines that have not seen IT in a while – but they are no longer Microsoft’s problem, and they should not really be yours either. You design for what is supported. The rest is goodwill.

The rendering engines behind each Outlook

Here is the heart of the page, and the thing almost no glossary covers cleanly. The engine under each version is what matters. The brand is just packaging.

Read that first row again. The classic Windows client renders email with the Microsoft Word engine. The document program. The thing you use to type letters and complain about its track changes. In 2026 you are coding for a layout engine that predates the iPhone.

Why the classic app uses Word (the short, bitter history)

The 2003 release was the last version that rendered email with Internet Explorer’s HTML engine. Then in 2007, Microsoft swapped the rendering engine to Word, reportedly to keep authoring and reading consistent. The fallout has shaped nearly two decades of email development.

The estimate from Email on Acid puts roughly 80% of email display bugs at the feet of the Word engine. That feels generous, honestly. It might be higher. Whole industries of workarounds – VML, MSO conditional comments, ghost tables – exist because one rendering choice in 2007 never got walked back.

Word was never built to render web pages. Asking it to is like asking a forklift to do dressage. It can sort of move in the general direction. The result is genuinely ridiculous.

The new Windows version is a completely different animal

Under the hood is WebView2, the same engine family as Microsoft Edge. That means real CSS support. Real flexbox, border-radius and real background images on divs. Media queries that actually fire. If you ignored email development between 2010 and 2024, this client is roughly what you assumed the brand meant that whole time.

There is one sharp gotcha. MSO conditional comments are ignored. That sounds bad. It is not. It means your existing classic workarounds stay invisible to the new engine, exactly as you would want. Ghost tables and VML, wrapped in <!--[if mso]> blocks, just do not render. So the two engines coexist without stepping on each other. What it does mean is that your old “I’ll just conditionally code for everything” plan needs a rethink, because the conditional path now only catches half your audience.

The quirks list – what the classic Windows client actually does to your HTML

This is reference material. Scroll here mid-build. The worst eight quirks of the Word-based version, named and one-paragraph-explained. Not the full encyclopaedia. The ones that keep biting.

No background images on tables and divs

Background images get stripped from most elements. VML is the only reliable fallback. The pattern is the “bulletproof background” technique – a VML rectangle inside an MSO conditional block, mirroring the table or section behind your image. It stays inert in every other client, so you can layer it without breaking anything.

Border-radius does nothing

Buttons render as sharp rectangles. No rounded corners, no matter what your CSS says. The accepted fix is the bulletproof button – a VML rectangle that paints a rounded shape behind a regular link, again wrapped in MSO conditional code. Search for “bulletproof button generator” if you want the boilerplate. There is no native fix.

Padding eaten on block elements

Padding on <div> and <p> evaporates but padding on <td> survives. This single quirk is most of why email developers still write nested tables in 2026. The related entry on nested tables goes deeper, but the short version: when the Word engine is in your matrix, you put your spacing on table cells, not on divs.

No max-width support

The CSS max-width property is ignored. Fixed widths declared as HTML attributes are the workaround. The double-declaration trick – width="600" plus style="width:600px" – exists because the engines disagree. The classic client reads the HTML attribute. Everything else reads the CSS. State both and everyone listens.

Line-height applied weirdly

The Word engine adds its own spacing to line-height and stretches text vertically in ways you did not ask for. The fix is one line: mso-line-height-rule: exactly; inside your style. It forces the classic renderer to honour the line-height you actually wrote.

120 DPI scaling chaos

This one is brutal and almost nobody covers it. On Windows machines with display scaling above 100% – which is most modern laptops with high-DPI screens – the classic app converts CSS pixel values to points inconsistently. Your 600px-wide email shows up at 720px or 800px on a high-DPI display, depending on the user’s scaling factor. The fix is a tiny block of MSO XML in your head that overrides PixelsPerInch. One paragraph of code that saves hours of “why is my email enormous on this one laptop” tickets.

Animated GIFs frozen on frame one

Versions 2007 through 2013 displayed only the first frame of animated GIFs. The 2016 release and later got better. The design rule never changed, though – your critical message and call to action live on frame one, regardless of what comes after. Anyone who designs an animation that depends on the user seeing frame three has not tested enough.

Web fonts mostly ignored

The classic client falls back from web fonts. Worse, if it sees a custom font at the start of your font stack, it sometimes skips the whole stack and renders Times New Roman. Times New Roman, in 2026. There is an attribute-selector workaround that hides the custom font from the Word engine while exposing it to other clients, but it is fiddly. The simpler approach is to keep web fonts for clients that can handle them and let the classic renderer fall back to a clean system font.

The easier siblings – Mac, web, and mobile

Stop treating the brand name as a synonym for classic Windows. The other variants are mostly fine, and treating them like equally broken is one of the reasons people overbuild.

The Mac app

Uses WebKit. Same engine family as Safari and Apple Mail. Most of the classic-Windows quirks listed above simply do not apply here. Background images work. Border-radius works. Padding behaves. If you have ever tested an email here after a long session of fighting the Word engine, the relief is real. It is basically Apple Mail with a Microsoft wrapper.

Outlook.com and the web version

The web interface runs a modern engine and supports a healthy slice of CSS. The main strangeness is dark mode – the webmail rewrites your inline styles into data-ogsc and data-ogsb attributes, which is its way of preserving your original colours while applying its own dark theme. You can target those attributes with CSS selectors if you want to control the dark variant. More on that below.

The iOS and Android apps

Different from desktop, with different rendering. The iOS app uses a WebKit-based engine and partially supports prefers-color-scheme. Android uses Chromium and applies algorithmic darkening similar to Gmail Android. Both handle modern CSS reasonably well. Neither needs VML. Neither cares about MSO conditional code. They are closer to Gmail mobile in spirit than to their desktop cousins.

Where ghost tables and VML are needed

So when a 2018 tutorial calls the brand “the rendering nightmare,” it is talking about one row of that table. The other five are fine. Knowing which variant your audience uses matters more than ever.

Dark mode in Outlook (the four-way split)

Dark mode does not have one answer here. It has four. Each variant handles the colour scheme its own way, and you cannot make them all look identical. The job is designing defensively rather than chasing pixel parity across them.

• Classic Windows. Applies its own dark-mode theme. Exposes proprietary attributes you can target – data-ogsc (original style colour), data-ogac (original attribute colour), data-ogsb (original style background), data-ogab (original attribute background).
• Outlook.com on the web. Same data-og* attributes. This is the most workable target of the four.
• Mac. Respects prefers-color-scheme reasonably cleanly.
• iOS and Android. Partial inversion, less reliable to target with media queries alone.

A minimal targeting snippet for the data-og attributes looks like this:

[data-ogsc] .body { background-color: #1a1a1a !important; }
[data-ogsb] .header { background-color: #16213e !important; }

Two extra signals help. Include the color-scheme and supported-color-schemes meta tags in your head. They tell the webmail and similar clients that your email knows what it is doing in dark mode, and the client backs off some of its aggressive rewriting.

Design rules that hold across all four. Avoid pure white logos – give them a transparent PNG with some breathing room. Avoid faint greys that turn harsh under inversion. Test the call-to-action button specifically, because that is what people click, and a button that loses contrast in dark mode loses revenue. The broader dark-mode discussion sits in the email-clients glossary entry; this section covers only the brand-specific split.

The migration – the 2026-to-2029 timeline that keeps moving

This is the freshest part of the topic, and the part most existing pages get wrong because the dates moved in early 2026. Worth getting the current picture right, because building for a deadline that has slipped is a recipe for redoing work.

Microsoft is migrating Windows users from classic Outlook to the new Outlook in three structured phases. Opt-in (now): users voluntarily switch. Opt-out: the new version becomes the default, but users can still switch back. Cutover: the fallback disappears, the classic app is removed from new installs.

The dates have changed. Here is where things actually stand as of mid-2026.

Read that fourth row twice. The opt-out has already slipped a full year, from April 2026 to March 2027. Microsoft’s own statement on the delay said it wants “12 months of lead time” and is still “delivering key features and improvements.” That is corporate-speak for “the new version is not ready for mandatory enterprise rollout.” Given Microsoft’s history with Office transitions, another slip is not off the table.

Why the “Outlook is dying” takes are wrong

The new Outlook still has feature gaps that matter to large organisations. VBA macro support, full PST parity, network share access, certain shared mailbox behaviours – all of these are partially missing or different. Microsoft confirmed that enterprise customers with a Microsoft 365 subscription can keep downloading and using classic Outlook even after cutover. So it is not vanishing on a neat schedule, and the email developers banking on it disappearing in 2026 are coding for their own inbox, not their audience’s.

For your build, the practical implication is plain. You code for two engines simultaneously until at least 2028. The Word engine is fading, not gone. The hybrid build holds.

How to actually build for Outlook in 2026

This is a glossary entry, so this is the posture, not a tutorial. The deeper how-to material lives in the nested-tables and css-preprocessors entries. The headline approach, though, fits in a few principles.

• Hybrid layout. A table-based base layout that works in classic Outlook, with modern CSS layered on top for everything else. Tables for the floor, CSS for the polish.
• MSO conditional comments. Feed the Word engine the workarounds inside <!--[if mso]> blocks. The new Outlook ignores them harmlessly. Other clients never see them.
• Double-declare widths. Set width="600" as an HTML attribute and style="width:600px" as CSS on the same element. The classic app obeys the attribute. WebKit clients obey the CSS.
• Inline your CSS. The Word engine tolerates <style> better than Gmail does, but inlining is still the safest baseline. A CSS preprocessor plus an inliner is the modern workflow.
• Ghost tables for column control. When you need columns to behave at a specific width in classic Outlook, wrap them in conditional MSO tables. The other engines ignore them.
• VML for backgrounds and rounded buttons. Use VML only when the visual matters and classic Outlook is in your audience. It is verbose and ugly. It also still works.

Build for the floor first, polish for the ceiling later. That single line covers most of what email developers learn the hard way over five years.

Testing across all the versions

You cannot eyeball six variants by hand. You probably own one – maybe two if you have a Mac and a Windows machine on the same desk. Real testing means real renders, which means a testing platform that previews across actual clients.

The realistic minimum matrix for a proper Outlook test pass:

1. Classic Outlook for Windows
2. New Outlook for Windows
3. Outlook.com on the web
4. Outlook for Mac
5. Outlook for iOS
6. Outlook for Android

Test each one in both light and dark mode. That doubles the matrix to twelve. Add Apple Mail and Gmail variants for non-Microsoft coverage and you are at the realistic floor.

The 2026 tool pricing reality

This part shifts often enough that stale tutorials mislead. Worth getting current.

Litmus changed its pricing hard after the Validity acquisition. As of 2026, the Core plan starts at $500 per month, covering 5 users and 2,000 previews. The cheap older tiers – the $99 Basic and similar – are gone. For a solo freelancer, that price stings. For a team shipping weekly campaigns where rendering bugs would cost real revenue, it can still pencil out.

Email on Acid is now under Sinch and remains the more budget-friendly competitor. A lot of small shops migrated there after the Litmus price change. Coverage is solid across all the variants you need.

Putsmail, the old free send-a-test tool, is no longer available. If a tutorial points you there, the tutorial is stale.

Whichever platform you pick, the rule holds. The bug always hides in the variant you skipped.

Outlook and the next five years

Nobody owns a crystal ball, and pretending to is a way to look foolish in 2029. But the direction is fairly clear, and building without an eye on the horizon is how you end up redoing work.

• 2026 to 2027. The classic Windows client still dominates B2B inboxes. The hybrid build stays mandatory. Watch the March 2027 opt-out date – given the slip history, do not be shocked if it moves again.
• 2027 to 2028. The new client becomes the default in more managed environments after the opt-out kicks in. CSS support across the broader category jumps overnight for many subscribers as their default engine shifts under them.
• 2028 to 2029. If cutover actually lands in March 2028 or later, the Word engine becomes a long-tail concern rather than a baseline one. Audited accessibility expectations – the European Accessibility Act style – become normal across email programmes.
• Beyond 2029. The rendering villain of the last two decades stops being one. The split between the old and modern engines closes for most senders.

One thing does not change across any of that. Real-client testing keeps mattering, because legacy classic installs persist for years after support ends officially. The Word engine fading does not mean it disappears. There will be a long tail of “still on Office 2021 because we never had budget” until well past the official dates.

Frequently asked questions

What is Outlook in email development?

It’s Microsoft’s email and calendar client family. For developers, it is six different rendering environments sharing one name – the classic Windows app (the Word engine), the new Windows client (Chromium-based), the Mac app (WebKit), Outlook.com on the web, and the iOS and Android apps. Each one handles your HTML differently, which is why a single email can look perfect in one place and broken in the next.

Why does Outlook break my HTML emails?

Because the classic Windows client renders email with Microsoft Word, not a browser. Word ignores most of modern CSS – flexbox, grid, border-radius, background images on divs, max-width, margins on block elements. The other variants – the new Windows client, the Mac app, the web version, the mobile apps – all use modern engines and render closer to web standards. So when people say “it broke my email,” they almost always mean the classic Windows version specifically.

What is the difference between classic and new Outlook?

The classic Windows client uses the Microsoft Word rendering engine, which dates back to 2007 and supports very limited CSS. The new Windows version uses WebView2, a Chromium-based engine in the same family as Microsoft Edge, and supports modern HTML and CSS. They currently coexist – users can switch between them, and Microsoft has delayed the mandatory enterprise rollout of the new version from April 2026 to March 2027.

Will Microsoft retire the Word rendering engine?

Yes, slowly. The new client is the long-term direction, and Office 2021’s desktop end-of-support arrives around October 2026. But the classic app stays supported through at least 2029 for Microsoft 365 subscribers and perpetual licence holders, and enterprises can keep downloading it separately even after the cutover phase. So the Word engine fades over years rather than months. Most email programmes need to support it through at least 2028.

Do I still need MSO conditional comments and VML in 2026?

Yes, for any audience that includes the classic Windows client – which is most B2B and enterprise lists. The new version ignores MSO conditional comments harmlessly, so the patterns coexist safely. You write the conditional block once. The Word engine sees it. Everything else, including the new client, treats it as invisible. That is exactly the behaviour you want.

Does the Mac app have the same rendering problems as the Windows version?

No. The Mac app uses WebKit, the same engine family as Safari and Apple Mail. It supports modern CSS very well. Background images, border-radius, flexbox – all work. The “breaks everything” reputation belongs almost entirely to the classic Windows client. If your audience is heavily on Mac, the picture is much less painful than the reputation suggests.

How does Outlook handle dark mode?

Differently across each variant. The classic Windows client applies its own dark theme and exposes data-ogsc, data-ogac, data-ogsb, and data-ogab attributes that you can target with CSS selectors. The web version uses the same data-og attributes. The Mac app respects prefers-color-scheme more cleanly. The iOS client partially supports the media query, while Android applies algorithmic darkening. The same email can produce four different dark-mode renders across the family alone.

What email clients should I test alongside these variants?

The realistic minimum is Apple Mail on iOS and macOS, Gmail on web, Android and iOS, the classic Windows client, the new Windows version, the web version, and mobile. Add one wildcard your own analytics flag – often Yahoo Mail or Samsung Mail. Test every one in both light and dark mode. Use Litmus or Email on Acid for previews, since you cannot reasonably own twelve clients yourself.

Key takeaways

• The name is not one email client. It is a family of six, each with its own rendering engine.
• The classic Windows version uses the Microsoft Word engine and is the source of nearly every “it broke my email” story.
• The new Windows client runs on WebView2 (Chromium-based) and handles modern CSS properly.
• The migration timeline keeps slipping. Enterprise opt-out is now March 2027, cutover no earlier than March 2028, the classic app supported through at least 2029.
• Use a hybrid build through at least 2028 – tables and MSO conditional code for the Word engine, modern CSS for everyone else.
• Test on real variants, not just one. The bug always hides in the version you skipped.

The honest summary is short. What used to be a single nightmare is now a category, and most of the category is fine. The one stubborn member – the classic Windows client on the Word engine – is finally on its way out, just very, very slowly. Until it goes, the hybrid build holds. After it goes, this glossary entry probably gets shorter.