Email signature generator › Outlook strips HTML

What Outlook removes from an HTML signature

People say Outlook strips HTML. What it really does is render incoming messages with the layout engine from Microsoft Word, which predates most of modern CSS. Knowing the exact list turns a mystery into a checklist.

What is discarded

The Word engine ignores, entirely: flexbox, CSS grid, float, position in all its forms, max-width and min-width, negative margins, background images on most elements, border-radius, box-shadow, opacity, and CSS transforms.

It handles unreliably: padding and margin on anything that is not a table cell, percentage widths, and line-height expressed without units.

It honours: tables, width and height as HTML attributes in pixels, cellpadding and cellspacing, inline style on table cells for colour, font-family, font-size and text-align, and images with explicit dimensions.

The rule that follows

Build the signature as a table. Put every style inline on the cells. Express every dimension in pixels as an HTML attribute where an attribute exists. Do spacing with cell padding or with an empty row of fixed height. Accept that rounded corners and shadows will not appear, and design something that looks finished without them.

This is not a degraded version for Outlook. It is the version, and it renders identically in every other client because there is nothing in it complex enough for a better engine to improve.

The separate problem: what the signature editor does

Distinct from rendering, Outlook's own signature editor rewrites what you paste. Pasting rendered content from a browser produces markup that Outlook has reinterpreted, often with its own conditional comments and Word-specific attributes added.

This is why a signature can degrade each time you edit it: you paste, Outlook rewrites, you copy from the editor, paste elsewhere, and the accumulated rewriting drifts further from what you built. Keep the source of truth in a file outside Outlook and always paste from that file, never from the last version Outlook produced.

Style blocks do not survive either

A <style> block in the head is not available to a signature, because a signature is a fragment inserted into a message rather than a document with a head. Even where a style block reaches the message body, Gmail strips it and Outlook applies it inconsistently. Every declaration has to be inline on the element it affects.

Checking what actually arrived

In Outlook, open a received message and use the option to view the message source. Search for your signature and read the markup that arrived. This is the only way to distinguish "Outlook stripped it" from "it never left in that form" — and the second turns out to be the case more often than people expect.

The conditional comment escape hatch

Outlook responds to conditional comments, a mechanism inherited from old Internet Explorer, which lets you supply markup that only Outlook sees: <!--[if mso]> ... <![endif]-->. Every other client treats the block as a comment and ignores it.

For a signature this is rarely worth using. It is a tool for email campaigns where a designed layout justifies maintaining two versions. A signature should be simple enough not to need one, and a signature that needs conditional markup is telling you it is too complex.

Where the Word engine surprises people most

Images get an unexpected border in some Outlook configurations when they are inside a link. Add border="0" as an attribute on the image, not only in CSS, which is the fix and looks archaic for a reason: it is.

Tables get extra space between cells even with padding set to zero, unless cellspacing="0" and cellpadding="0" are present as attributes and border-collapse:collapse is set inline. All three, every time.

How much of this is still true

Microsoft has been moving Windows users to a new Outlook built on web technology, which renders with a browser engine and does not have these limitations. As that transition proceeds the constraints ease. It has been proceeding for some time, and a significant share of business users are still on the classic client — so building for the Word engine remains the safe choice until you have a reason to believe your specific recipients have moved.

Frequently asked questions