A signature that looks perfect in Outlook on the web silently mangles in Outlook desktop on Windows. Here's the renderer split that causes it, and how to ship one signature that survives both.
The MailSigCraft Team
MailSigCraft
You paste your signature into Outlook on the web, send a test, and it looks exactly like the designer's preview. Your colleague on classic Outlook for Windows opens the same draft and sees logo bloat, double line spacing, and a layout that wraps wrong. Nothing about the HTML changed between the two clients — but the renderer did, and that's the whole story.
This post explains why "Outlook" splits into two completely different rendering engines, what specifically breaks across the boundary, and how to design one signature that survives both without forking the HTML.
When someone says "Outlook," they could mean any of these:
outlook.office.com or outlook.live.com) — runs in the browser, uses the browser's HTML engineThe first two are essentially the same engine (a Chromium-based browser). The third is the outlier — classic Outlook for Windows uses Word's HTML engine, which predates flexbox by a decade and renders email like it's 2007. The fourth and fifth are their own thing.
For "Outlook 365 vs Outlook desktop" the practical split is browser-engine clients vs Word-engine classic Outlook. That's the boundary where signatures actually break.
Flexbox, grid, gap, calc(), CSS variables, aspect-ratio — all of these work in Outlook on the web and the new Outlook, and all of them are silently ignored by Word's renderer in classic Outlook. A two-column logo-and-text signature laid out with display: flex renders side-by-side in the web client and collapses to a single vertical stack in classic.
The fix is to design for the Word renderer first. Use nested <table> elements for every layout decision. Set cellpadding="0" cellspacing="0" border="0" on every table to remove default Word table chrome. The result renders identically in both engines — Word's tables and Chromium's tables agree on the basics.
Classic Outlook scales font sizes based on Windows display DPI and Word's own zoom level, not by honouring CSS pixel sizes exactly. A signature designed at font-size: 14px in the web client typically renders 15–30% larger in classic Outlook on a high-DPI display. Vertical spacing inflates proportionally.
The fix is to specify font sizes in pt (Word's native unit) instead of px. font-size: 10.5pt renders consistently across both engines; font-size: 14px does not.
Word's HTML renderer adds its own paragraph margins around <p> and <div> tags on top of whatever CSS specifies. A signature with three lines of contact info ends up with twice the vertical white space in classic Outlook compared to the web client.
The fix is to use single-cell <td> elements with explicit line-height and no <p> or <br> between lines where possible. Set mso-line-height-rule: exactly (Microsoft's proprietary CSS hint) and Word will respect the declared line height instead of adding its own.
Outlook on the web requests external images on render — they show up immediately. Classic Outlook for Windows treats externally-hosted images as a privacy risk and blocks them by default, showing "Click here to download pictures" or a red X.
Two ways to fix this:
https:// URLs (never http://) with a long Cache-Control max-age survive Outlook desktop's image-download prompt for most senders the recipient has already corresponded with.Microsoft 365 has a feature called roaming signatures (aka cloud signatures) that's supposed to sync your signature across Outlook on the web, the new Outlook, and recent builds of classic Outlook. In practice, the cloud signature is created and edited in the web client — so it's authored against the web renderer, with no knowledge of the Word-engine quirks above.
When the cloud copy syncs down to classic Outlook, the same signature now has to render through Word. If it was designed with flexbox or px font sizes, the desktop renders it broken even though the web version looks fine. The signature didn't change — the renderer did.
The fix is to author the master signature against the Word renderer (tables, pt units, cellpadding=0), then let it sync. A signature that renders correctly in classic Outlook will always render correctly in the web client; the reverse is not true.
If you need a desktop-only fallback — say, swapping a background-image for a real <img> element because Word ignores CSS backgrounds — Outlook's conditional comments let you target classic Outlook precisely:
<!--[if mso]>
Only classic Outlook for Windows renders this.
<![endif]-->
<!--[if !mso]><!-->
Every other client renders this. Classic Outlook ignores it.
<!--<![endif]-->
Use this sparingly. Forking the HTML across renderers is a maintenance burden — most signatures can be designed once for the Word engine and shipped everywhere. Reach for conditional comments only when a single design genuinely can't satisfy both engines (VML graphics, Outlook-specific button rendering).
The reliable workflow is to design once against the strictest renderer and let everything else inherit:
pt for font sizes, system fonts only, cellpadding="0" cellspacing="0" border="0" everywhere, inline CSS via the style="" attribute on each cell. No flexbox, no grid, no CSS variables, no web fonts.The full cross-client breakdown is in 9 things that break email signatures across Gmail, Outlook, and Apple Mail. The deeper "my Outlook signature isn't showing at all" troubleshooting is in Outlook email signature not showing.
Build the signature in the MailSigCraft editor and the desktop-safe defaults are already applied — table-based layout, pt units, system fonts, inline styles, conditional-comment fallbacks where they matter. The output paste-tests across web and desktop without changes.