Why your email looks broken in Outlook — and the rules that fix it

1. Outlook is Word, not a browser

Every other client you test in is a browser engine wearing a mail client's clothes. Gmail's web app, Apple Mail, Yahoo, Outlook.com — all of them parse your HTML with something descended from a rendering engine built for the web, then strip a documented list of things they do not allow.

Classic Outlook for Windows is different in kind, not degree. Since Outlook 2007, Microsoft has rendered HTML email using the Word layout engine — the same one behind .docx. It was a deliberate choice about security and authoring consistency, and the practical consequence is that your email is being laid out by a word processor that has never heard of the last fifteen years of CSS.

2. Which Outlook are we talking about?

This is where most "but it works for me" arguments come from. "Outlook" is at least four different renderers sharing one brand, and only some of them are the problem.

So when a client says "it's broken in Outlook", the useful first question is which one. If the screenshot shows square corners where you drew rounded ones and Times New Roman where you specified a brand font, you are looking at the Word engine — and everything below applies.

3. The properties Word silently drops

Nothing errors. Nothing warns you. The declaration is simply not applied, and your email renders as though you never wrote it. These are the nineteen properties our Outlook profile strips, because the Word engine does not honour them:

Read that list again with one question in mind: how much of my layout depends on any of these? If the answer is "the whole card component", that component needs a table-based twin for Outlook.

4. The Times New Roman trap

This is the single most reported Outlook surprise, and the mechanism is worth understanding because the fix is one line.

Outlook resolves font-family against fonts Word knows. Our Outlook profile keeps only these, and drops everything else from the stack:

Arial, Helvetica, Helvetica Neue, Verdana, Tahoma, Georgia, Times, Times New Roman, Courier, Courier New, Trebuchet MS, Segoe UI, Calibri, Cambria, Garamond, Book Antiqua, Palatino — plus the generic families sans-serif, serif, monospace and cursive.

Now the trap. If your stack is font-family:'Brand Sans', 'Brand Sans Fallback' and neither name survives, Outlook does not pick a reasonable default sans-serif. It renders Times New Roman. Your clean modern email arrives looking like a 1997 memo, and only in Outlook — so it passes every other check you ran.

/* breaks in Outlook — no Word-safe name anywhere in the stack */
font-family: 'Brand Sans', 'Brand Sans Text';

/* survives — the last two names are always resolvable */
font-family: 'Brand Sans', Arial, Helvetica, sans-serif;

Web fonts are a separate matter: Outlook, Gmail and Yahoo do not load @font-face or fonts.googleapis.com at all. Declare them if you like, but the fallback is what most of your list will actually see — so choose it as deliberately as you chose the brand face.

5. Layout: why your div collapsed

Three separate behaviours combine into the classic "my beautiful two-column layout stacked and lost all its spacing" bug report:

1. display:flex and display:grid fall back to block. Every child stacks full width, in source order. No columns, no alignment, no gap.
2. Padding on a <div>, <p> or <span> is dropped. Word applies padding to table cells. Your careful 24px interior spacing vanishes and the text runs to the edge.
3. max-width is ignored. A fluid container that relies on max-width:600px to stop growing will happily fill the whole reading pane.

The rules that survive all three are unglamorous and completely reliable: lay out with nested tables, set widths with the HTML width attribute as well as CSS, and put your padding on <td> elements.

<!-- padding on the div: gone in Outlook -->
<div style="max-width:600px;padding:24px;">…</div>

<!-- padding on the cell, width declared twice: renders everywhere -->
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0"
       style="width:600px;">
  <tr><td style="padding:24px;">…</td></tr>
</table>

role="presentation" is not decoration. It tells screen readers this table is a layout device, not data — see the accessibility article for why that one attribute changes how the whole email is announced.

6. Background images need VML

A CSS background image is not a background image to Word. Both background-image:url(…) and the url() half of the background shorthand are dropped outright. If you set a hero image as a background and put your headline on top of it, Outlook shows the headline on a blank area — and if you never set a background colour, that headline may be white text on white.

The fix is VML: Vector Markup Language, an old Microsoft vector format the Word engine still draws. Wrapped in an Outlook-only conditional, it paints the image behind your content for Outlook while every other client uses your normal CSS.

<td background="hero.jpg" bgcolor="#0d3f9e"
    style="background-image:url('hero.jpg');background-size:cover;">
  <!--[if gte mso 9]>
  <v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true"
          stroke="false" style="width:600px;height:320px;">
    <v:fill type="frame" src="hero.jpg" color="#0d3f9e" />
    <v:textbox inset="0,0,0,0"><![endif]-->
    <div>…your headline and CTA…</div>
  <!--[if gte mso 9]></v:textbox></v:rect><![endif]-->
</td>

Note the bgcolor and the color on the fill. Always set a solid colour behind a background image anyway — it is what shows when the image is blocked, which in Outlook is the default state.

7. Conditional comments and ghost tables

Conditional comments are the escape hatch that makes all of the above workable. They are ordinary HTML comments to every client except Outlook, which reads them as instructions:

• <!--[if mso]> … <![endif]--> — content only Outlook sees. Every other client treats it as a comment and skips it.
• <!--[if !mso]><!--> … <!--<![endif]--> — content everyone except Outlook sees.

The most common use is the ghost table: a fixed-width table that exists purely to give Outlook the container it needs, wrapped around a fluid div that every modern client uses instead. This is the fluid-hybrid pattern, and it is how one build serves both worlds.

<!--[if mso]>
<table role="presentation" width="600" cellpadding="0" cellspacing="0"><tr><td>
<![endif]-->

  <div style="max-width:600px;margin:0 auto;">…</div>

<!--[if mso]>
</td></tr></table>
<![endif]-->

Look closely at that markup and you will see the trap: the opening <table><tr><td> and its closing tags live in two different comments, with your content between them. The HTML is only valid once Outlook activates both blocks and the fragments meet. Get the count wrong — one opening ghost table, no closing block — and Outlook renders a broken tree while every other client, which ignored both comments, looks perfect.

8. SVG, GIF and the first-frame rule

Two image behaviours catch people out on the day of the send.

SVG does not render in the Word engine — at all. An <img src="logo.svg"> becomes an empty box the size of its declared dimensions, showing the alt text if you wrote any and nothing if you did not. Inline <svg> markup is stripped too (Gmail strips it as well). Export logos and icons to PNG for email, however tempting a crisp vector is.

Animated GIFs show only their first frame in Outlook 2007–2019. Not a fallback image — literally frame one of the animation. If your GIF builds to the offer over four frames, Outlook subscribers see the setup and never the punchline. Put the offer, the price and the CTA in the first frame, always.

9. mso-hide and your preheader

One Microsoft-only property genuinely works, and it matters: mso-hide:all actually hides an element in Outlook. That is how hidden preheader text — the line that shows in the inbox list next to the subject, but not in the email body — stays hidden there.

A preheader typically stacks several tricks so that every client hides it: display:none, a zero or 1px font size, zero max-height, opacity:0, white-on-white colour, and mso-hide:all for Outlook. That combination is deliberate, not a bug — worth remembering when a checker flags white text on a white background. Ours deliberately does not: hidden blocks are excluded from the contrast check for exactly this reason.

10. The rules, as a checklist

Everything above, compressed into the things to actually do:

1. Lay out with nested tables, not divs with flexbox. Add role="presentation" to every layout table.
2. Declare width twice — the HTML width attribute and CSS width — and never rely on max-width alone.
3. Put padding on <td>, never on the div or paragraph inside it.
4. End every font stack with a web-safe face and a generic family, or Outlook hands you Times New Roman.
5. Build buttons as tables, not as CSS-rounded links — square corners in Outlook are the giveaway that you did not.
6. Give every background image a VML fallback and a solid bgcolor underneath it.
7. Balance your [if mso] blocks, and count them — the failure is invisible outside Outlook.
8. No SVG. First frame of every GIF carries the message.
9. Inline your CSS. Outlook drops linked stylesheets and @import, and reads none of your @media queries on the desktop client.
10. Check the email, not the design — run the built HTML through a pre-flight before it reaches a real inbox.

Frequently asked questions