Outlook on Windows renders HTML email using Microsoft Word's rendering engine. Not a browser engine — the same layout engine that renders documents. That single fact explains almost every strange Outlook bug, and once you know it the fixes stop being folklore.
Word does not support most modern CSS, handles box models differently, and has its own opinions about spacing that it will apply whether or not you asked.
The rendering engines you are building for
| Client | Engine | Consequence |
|---|---|---|
| Outlook Windows (desktop) | Microsoft Word | Very limited CSS, no float, no flexbox |
| Outlook.com and Outlook mobile | Web-based | Much better, but forces its own dark mode |
| Outlook for Mac | WebKit | Behaves reasonably |
| Gmail web | Chrome-based | Strips <style> in some contexts, no support for some selectors |
| Gmail apps | Varies | Clipping on long emails |
| Apple Mail | WebKit | The most capable client |
Testing on Apple Mail and declaring victory is the most common mistake in email development, because Apple Mail is the client least likely to reveal a problem.
The specific Outlook problems and their fixes
Margins are ignored. Word does not reliably apply CSS margin. Use padding on table cells instead, or empty spacer rows with an explicit height. This is why HTML email is still built with tables — not nostalgia, but because table cells are the one box model Word handles predictably.
Line height is applied unpredictably. Set line-height in points rather than a unitless multiplier, and add mso-line-height-rule: exactly before it. Without that rule Word applies its own leading and your careful spacing collapses.
Background images do not render. Word has no support for CSS background images. The workaround is a VML block in a conditional comment — the v:rect / v:fill pattern — which is verbose and works. Or design so the background image is decorative and the email survives without it.
Rounded corners do not render. border-radius is unsupported, so your rounded button appears square. This is acceptable, so long as the button still reads as a button. If it must be rounded, that means images, which brings the image blocking problem instead.
Extra space appears under images. Add display: block to the image and font-size: 0; line-height: 0 to the containing cell. This is the single most common "why is there a gap" bug.
Emails wider than 600px break. Outlook's page setup effectively enforces a limit. 600px remains the safe maximum width for a reason that has nothing to do with phones.
Anchor colours revert. Outlook and some other clients override link colours. Set the colour on the <a> element itself with !important, and wrap the link text in a <span> with the same colour as a belt-and-braces fallback.
Text scales oddly at 120 DPI. Windows display scaling affects Outlook's rendering. Setting explicit pixel widths on tables and using the mso- DPI reset in a conditional comment addresses the worst of it.
Gmail's separate quirks
Long emails get clipped. Gmail truncates messages over roughly 102KB and shows "View entire message". Everything below the fold — including your unsubscribe link — disappears behind that click, and tracked opens still register. Keep the HTML under 100KB, which mostly means not inlining enormous amounts of unused CSS.
<style> blocks are stripped in some contexts, particularly in forwarded messages and some app versions. Inline your critical styles and treat the <style> block as an enhancement, not a foundation.
Some CSS selectors are unsupported, so build with simple class and inline styles rather than descendant selectors.
The approach that avoids most of it
Build simply. A single-column, table-based layout with padding for spacing, inline styles, HTML buttons and no background images renders correctly nearly everywhere with no client-specific hacks.
Complexity is where the bugs live. Each additional column, each background image, each rounded corner is a place where one of eight clients does something different — which is also the reason most interactive email never justifies its build cost. The plainest version of your email is also the most robust, which is a large part of why plain-looking HTML has become the default among senders who care about results.
Then test properly. The minimum set is Outlook on Windows, Gmail web, Gmail on Android, Apple Mail on iOS, and Outlook.com — because between them they cover every engine above. Add dark mode and images-off passes and you have a real testing checklist.
Frequently asked questions
Why does Outlook render email differently from every other client?
Because Outlook on Windows uses Microsoft Word's rendering engine rather than a browser engine. Word supports a small subset of CSS and applies its own layout rules, which is why margins, background images and rounded corners fail there and work elsewhere.
Why is there a gap under images in my email?
Images are inline elements by default, so the client reserves space for a text baseline underneath. Set display: block on the image and zero out font-size and line-height on the containing cell.
Why does Gmail clip my email?
Gmail truncates messages above roughly 102KB. Anything below the cut, including the unsubscribe link, is hidden behind "View entire message". Keep your HTML under 100KB by removing unused CSS and avoiding enormous inline data.
Do I still need to use tables for email layout?
For anything that must render correctly in Outlook on Windows, yes. Word's engine does not support float or flexbox, so table cells with padding remain the only layout mechanism that behaves predictably across every major client.
