On paper, an email signature is a small piece of HTML. In practice, the HTML you write is not the HTML the recipient sees. Three rendering engines — Microsoft Word (powering Outlook on Windows), WebKit (powering Apple Mail and iOS), and Gmail's sanitizer — all interpret your code differently, strip different parts of it, and apply different defaults. This is a short field guide to the differences that matter.
Outlook on Windows: the Word problem
Outlook on Windows uses Microsoft Word as its rendering engine for email content. This is the source of almost every cross-client compatibility issue. Word does not understand modern CSS — no flexbox, no grid, no `display: inline-block`, no `border-radius` reliably, no SVG. The pragmatic answer is to lay out signatures as nested HTML tables, exactly like email developers were doing in 2008.
A subtler problem is Outlook's habit of inserting a blank line — a `<p>` with non-breaking space — before any signature it does not recognize. This breaks the visual flow and is hard to debug because the line only appears when the signature is loaded into Outlook's native signature manager. The workaround is to start the signature with a zero-height table that "absorbs" the inserted paragraph.
Gmail: the 102KB rule and inline-only CSS
Gmail strips `<style>` blocks in most email contexts and requires CSS to be inline on each element. This is fine for signatures, which are small, but it means you cannot use class-based styling. It also means that any media queries you might want to use (for mobile-specific styles) need to live in inline `<style>` tags within `<head>` — which Gmail does respect for inline emails, but not always for signatures injected via API.
The 102KB clipping rule is the more visible issue. If your email body plus signature plus quoted history exceeds 102KB, Gmail clips the message and shows "[Message clipped]" with a "View entire message" link. The signature often ends up below the clip point. Keep signature image weight under 30KB total, and use hosted images rather than inline base64.
iOS Mail and Apple Mail: WebKit-friendly, but signature-hostile
WebKit (Apple's rendering engine) is the most modern of the three. It supports almost everything you would expect a browser to support. The hard part with Apple Mail is not rendering — it is deployment. iOS Mail does not support HTML signatures in its UI; you can only enter plain text. To deploy an HTML signature on iOS, you need an MDM profile, a server-side rewrite, or a workaround using the iOS Shortcuts app. None of these are friendly.
Apple Mail on macOS does support HTML signatures, but only via the `~/Library/Mail/V*/MailData/Signatures/` folder, which the user cannot easily access. The official path is to import a `.mailsignature` file or to use a third-party tool that writes the signature to the right location.
Patterns that work in all three
- Use nested HTML tables for layout, with `cellpadding="0" cellspacing="0" border="0"`.
- Inline all CSS via `style=""` attributes; do not use classes or stylesheets.
- Use absolute pixel widths, never percentages.
- Specify font sizes in `pt` for Outlook and in `px` as a fallback. Test both.
- Use web-safe fonts (Arial, Helvetica, Georgia) with a single fallback. Do not embed custom fonts.
- Host all images on a stable CDN. Specify exact `width` and `height` attributes on every `<img>`.
- Avoid SVG, base64, and CSS background images.
- Test in Outlook 2019, Gmail web, and iOS Mail before shipping. If you have time, also test in Outlook on Mac and OWA.
