- What Word's engine does to your markup
- The fixes that earn their keep
- When an image is the honest answer
- Images without tanking deliverability
- A sane default
You build an email, it looks right in the browser preview and in Gmail, and then someone opens it in Outlook on a Windows desktop and the layout is soup. Columns stack, buttons lose their shape, the background image has vanished.
This is not your CSS. Classic Outlook on Windows renders HTML email with Microsoft Word's engine, and has done since Outlook 2007. Word was designed to print documents. Asking it to behave like a browser is where every Outlook bug starts. This article covers what survives Word, the fixes that are worth your time, and the point at which rendering part of the email as an image is the pragmatic answer.
What Word's engine does to your markup
The Word engine has no flexbox, no grid and no CSS positioning. max-width is ignored, which is why fluid layouts blow out to full width. Background images on ordinary elements are dropped. border-radius does not exist, so buttons come out square. Padding is respected on table cells but unreliable on divs, and margins are shaky everywhere.
What does work: tables, explicit widths, bgcolor, inline styles on table cells, and images with hard pixel dimensions. Which is why, in 2026, production email still looks like 2004 under the hood: nested tables with role="presentation" and every style inlined.
Two caveats before you write off Microsoft entirely. The new Outlook for Windows and Outlook on the web use a proper web renderer and behave far better. But classic desktop Outlook remains standard kit across corporate estates, so if you send to businesses, you are building for Word for years yet.
The fixes that earn their keep
You cannot patch Word into being a browser, but a few techniques cover most of the gap.
Build the skeleton from tables. One outer table for the 600px shell, inner tables for rows and columns. Add role="presentation" so screen readers skip the scaffolding.
<table role="presentation" width="600" cellpadding="0" cellspacing="0" align="center">
<tr>
<td bgcolor="#0f172a" style="padding: 32px; color: #ffffff;
font-family: Arial, sans-serif; font-size: 16px; line-height: 24px;">
Real text goes here, not an image of text.
</td>
</tr>
</table>
Use mso conditional comments to hand Outlook its own instructions. Only Word's engine reads these, so you can feed it a fixed-width table while everyone else gets the modern markup:
<!--[if mso]>
<table role="presentation" width="600" align="center"><tr><td>
<![endif]-->
<div style="max-width: 600px; margin: 0 auto;">
Content for clients that understand max-width.
</div>
<!--[if mso]>
</td></tr></table>
<![endif]-->
Make buttons from a padded cell with a bgcolor rather than a styled anchor, so they stay button-shaped without border-radius. Background images are possible through VML, but every VML block is another chunk of markup only one engine reads. Keep it for the hero, not for every section.
When an image is the honest answer
Some parts of an email are simply not worth rebuilding in table-safe HTML. A chart. A ticket with a QR code. A price comparison grid. A product card with overlapping elements. If a fragment needs CSS you would actually enjoy writing, it will not survive Word.
The pragmatic pattern is a hybrid. Keep the message itself as real text on a table skeleton, and render the intricate fragment as a PNG on the server, from the same template your web app already uses. Word displays a picture with fixed dimensions perfectly, every time. We have used this approach for invoices, receipts, vouchers and product cards in Laravel, and there is a good rundown of making images render consistently across email clients on the HTML to Image blog, covering the client quirks that still apply once the image is in.
Images without tanking deliverability
Image-heavy email has its own failure modes, so a few rules keep you out of trouble.
Never send an all-image email. Spam filters score against a high image-to-text ratio, and a recipient with images off sees nothing at all. The message lives in text; images carry the parts text cannot.
Always write meaningful alt text, and put the actual numbers in it, so the email still works before images load:
<img src="{{ $chartUrl }}" width="600" alt="Renewals this week: 214, up 18%"
style="width: 100%; max-width: 600px; height: auto; display: block;">
Send retina. Render at twice the display size and set the display width in the markup, so the image is sharp on every screen. Host images on your own domain with long cache headers, and keep a "view in browser" link in the header for the worst case.
A sane default
Table skeleton, real text, inline styles, mso comments where Outlook needs its own path, and a server-rendered image for anything with real design in it. Then test in the actual client: Litmus, Email on Acid, or a cheap Windows VM with classic Outlook installed. The engine is from 2007; your process does not have to be.
Related articles
