Email signatures look pixel-perfect in one client and mangled in another. Here are the nine specific things that cause cross-client rendering failures — and the fix for each.
The MailSigCraft Team
MailSigCraft
You build a signature that looks perfect in Gmail's web app, your CEO opens it in Outlook on Windows, and sees a wall of broken layout, missing images, and wrong fonts. This is the cross-client rendering problem: every major mail client uses a different HTML engine, and a signature that ships needs to survive all of them.
This post covers the nine specific things that break across Gmail, Outlook (desktop and web), and Apple Mail — plus the fix for each.
Mail clients aren't browsers. Gmail's web client renders HTML through its own sanitizer that strips unknown tags. Outlook on Windows uses Microsoft Word as its rendering engine — yes, Word — which has no support for flexbox, grid, or most CSS3. Apple Mail uses WebKit, which is closest to a real browser but still has its own quirks around image sizing and dark mode.
A signature can pass three QA checks and break on the fourth. The fix isn't picking one client and hoping. It's designing to the lowest common denominator — table-based HTML with inline styles — and testing in all three.
Gmail and Outlook both strip <link rel="stylesheet"> and most <style> blocks before delivery. Any styling that lives in an external file or a <head> block silently disappears.
Inline every CSS rule with the style="" attribute on each element. Tools like juice automate this — MailSigCraft inlines all styles by default before you copy.
Outlook desktop on Windows uses Word's HTML engine, which predates flexbox and grid by a decade. display: flex is silently ignored; the layout collapses to a vertical stack.
Use <table> elements for every layout decision — multi-column signatures, side-by-side logo and text, all of it. Set cellpadding="0" cellspacing="0" border="0" to remove default table chrome.
Relative paths don't resolve in mail clients. <img src="logo.png"> works in your dev preview and renders as a broken image in every recipient's inbox.
Every <img> needs a fully-qualified https:// URL. MailSigCraft hosts uploaded images on a CDN automatically. If you're hand-rolling the HTML, use imgix, Cloudinary, or your own static host.
Apple Mail (macOS and iOS) renders images at native pixel size by default. A 200×200 logo intended for 32px display shows up at 200×200 — comically large.
Set explicit width="" and height="" attributes on every <img> and export the source asset at 2× the display size (64×64 for a 32px display) for crisp rendering on both Retina and standard screens.
Custom fonts loaded via <link> or @import are stripped (see #1). Even fonts referenced inline with style="font-family: 'Custom Sans'" fall back to system fonts when the font file isn't bundled — and most clients block font-bundling for security reasons.
Use a system font stack: font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Arial, sans-serif. The signature renders in the local system font on every device — consistent and crisp.
background-image: url(...) on a <td> or <div> is silently dropped by Outlook desktop's Word renderer. The cell renders with no background.
Use a real <img> element instead, or VML fallback for Outlook (<!--[if mso]>...<![endif]--> conditional comments). For signatures specifically, avoid backgrounds entirely — they rarely survive the round-trip.
Gmail iOS and Apple Mail macOS partially auto-invert signatures in dark mode. A logo on a white background may end up on a near-black background, with the original transparent edges suddenly visible as halos.
Either commit to a transparent-background design that works on both light and dark, or wrap the signature in a <table bgcolor="#ffffff" style="background-color: #ffffff !important;"> to force a white background even in dark mode. See the dark mode survival guide for the deep dive.
Outlook 2007–2016 chokes on three-character hex codes like #fff — it interprets them as malformed and falls back to default black. Modern Outlook handles them, but older deployed versions still don't.
Always use six-character hex (#ffffff, not #fff). Two extra characters per color removes an entire class of legacy rendering failures.
Gmail's signature storage caps at 10,000 HTML characters. Pretty-printed, indented HTML is 10–20% larger than minified output, and the overhead adds up — especially with base64-embedded images.
Minify the final HTML before pasting, host images on a CDN instead of inlining them as base64, and check the character count before pasting. Full breakdown in Why your Gmail signature is being cut off.
Outlook desktop (Windows) — the strictest renderer. If it works here, it works everywhere.
Gmail web — the most-used renderer.
Apple Mail macOS — your design lives or dies on this one's dark mode handling.
Gmail iOS app — the most-used mobile renderer.
Build the signature in the MailSigCraft editor and you skip all nine — every signature is exported as inline-styled, table-based, system-font, CDN-hosted, minified HTML by default. The output paste-tests across all three clients without changes.