Why Outlook Strips Your Email CSS (and How to Fix It)

Published

If you’ve ever built an email that looks perfect in your browser and then opens in Outlook looking like a plain, unstyled Word document, you’ve run into Outlook’s Word rendering engine. Since Outlook 2007, desktop Outlook on Windows has used Microsoft Word — not a browser engine — to render HTML email. Word is a document editor, not a web renderer, and it strips or ignores most of the CSS a browser would happily apply.

What actually gets stripped

Specifically, Word’s engine:

  • Removes <style> blocks from the <head> entirely
  • Ignores CSS classes and IDs in most cases (so your stylesheet selectors do nothing)
  • Doesn’t support modern layout CSS like flexbox or CSS grid
  • Has partial or inconsistent support for background images, some positioning properties, and CSS3 features in general
  • Falls back to Times New Roman if the specified font isn’t recognized as web-safe

The one thing it does reliably read: inline style attributes written directly on individual HTML elements.

Why other email clients matter too

Outlook is the strictest offender, but it’s not the only one. Gmail strips <style> blocks in some contexts (particularly the web app, less so some other surfaces). Apple Mail and Yahoo Mail are more forgiving but still inconsistent across their various app and webmail versions. Because support varies this much across clients, inlining CSS isn’t an “Outlook workaround” — it’s the baseline standard the entire email industry uses, precisely because no single set of rules works everywhere except “put every style directly on every element.”

A worked example

Take this normal, browser-valid HTML:

<style>
  p { color: #0D9488; font-family: Arial, sans-serif; }
</style>
<p>Hello there.</p>

In a browser, that paragraph renders teal, in Arial. In Outlook, the <style> block is discarded before rendering even starts — the paragraph renders in default black, in Times New Roman, because nothing told it otherwise at the element level.

The inlined equivalent:

<p style="color: #0D9488; font-family: Arial, sans-serif;">Hello there.</p>

This version carries its own styling with it, element by element, so there’s no external stylesheet for Outlook’s engine to discard, and it renders consistently across Outlook, Gmail, Apple Mail, and other major clients because it doesn’t depend on the client supporting <style> blocks or selectors at all. That said, “consistently” isn’t “identically” — some clients still apply their own adjustments (like Outlook.com or Apple Mail’s dark-mode color handling) that inlining alone can’t control. Inlining solves the specific problem this post is about — styles surviving at all — not every possible rendering difference.

Doing this by hand doesn’t scale

For a one-line email this is trivial. For a real newsletter with a dozen paragraphs, several headings, a couple of links, and a list, manually copying the same style declarations onto every element — and updating all of them again if you change your color palette — gets tedious and error-prone fast. That’s the specific problem our Markdown to Email HTML Converter solves: write normal Markdown, and it outputs fully inlined, Outlook-safe HTML automatically, entirely in your browser.