Why your HTML email signature breaks in half your recipients' inboxes

You design a signature. It looks sharp in your browser preview. You paste it into Gmail, send a test to a colleague, and they write back saying the photo is missing and the layout has collapsed. This happens constantly. Not because the HTML was wrong, but because email clients are not browsers -- and nobody tells you that until after you've already wasted an afternoon on it.

Email signatures are deceptively hard to get right. The visual builder looks simple. The real problem is underneath: email HTML in 2026 still has to play by rules written around the time Internet Explorer 6 was current.

Email HTML is not web HTML

Modern web design relies on flexbox, CSS Grid, and media queries. None of those work reliably in email. Not because email clients are slow to adopt them, but because several major clients use rendering engines that were never designed to display web pages.

Microsoft Outlook on Windows uses the Word document rendering engine to process HTML emails. The same engine that handles .docx files. It was built for word-processed documents -- not for grid layouts and responsive breakpoints. Flexbox, CSS Grid, absolute positioning, and float are not supported. Margin shorthand values may be ignored or partially applied. Background images require a proprietary XML workaround using Vector Markup Language.

Gmail runs your email through a sanitizer before displaying it. The sanitizer strips every style block out of the document head, removes external CSS links, and rewrites class names with random prefixes, breaking any surviving class-based selectors. Inline CSS survives, but only properties on Gmail's internal whitelist. Negative margins are discarded. Any style block containing a background-image URL is removed in full.

Apple Mail uses WebKit, which is the closest thing to a real browser in the email world. It supports media queries, padding, and most modern CSS properties. It's also the least representative of what most business recipients will see -- which is why testing in Apple Mail alone gives you false confidence.

A signature built with flexbox and CSS classes will look fine in Apple Mail, might render in Outlook if you're lucky, and will fall apart in Gmail.

Tables are still the answer

The solution email developers landed on twenty years ago is still the right one: use HTML tables for layout. Not because tables are semantically ideal, but because they're the one layout mechanism every email client actually handles. Outlook, Gmail, Yahoo, and webmail clients on corporate intranets from 2009 all support them.

This means a signature should not use a div with flexbox to place an avatar next to your name. It should use a table with rows and cells. Every layout property should be set inline, directly on the element -- not in a class. Padding should go on table cells, not divs. Outlook on Windows only honors padding set on table cells.

You shouldn't have to write this by hand. But if you paste code from a generic web tutorial into a signature, you'll likely get something that looks good in Chrome and breaks in Outlook.

Image embedding: the three options and their tradeoffs

When you include a photo or logo in an email signature, you have three ways to deliver that image. Each comes with different failures.

Hosted URL: The image lives on a web server, and the HTML tag points to an external URL. This is how images work on the web. The problem is that many email clients block remote images by default. Outlook on Windows shows a placeholder and a security prompt. Corporate mail gateways sometimes strip external requests entirely. If your recipient has "block external images" enabled -- many enterprise users do -- your photo doesn't appear.

Base64 data URI: The image is encoded directly into the HTML as a long string of characters. No external request needed, so remote-image blocking can't hide it. The tradeoff is size: base64 encoding adds roughly 33% to the image's byte count, and some spam filters flag emails with large embedded data blocks as suspicious.

There's also a specific problem with Gmail. Gmail web often doesn't display base64-encoded images at all. The browser's Content Security Policy and Gmail's own sanitizer both treat data URIs as potential security vectors. Gmail mobile may render them; Gmail web may not. You could have an avatar that shows up for Outlook recipients and disappears for Gmail recipients.

CID (Content-ID): Images are attached to the email as MIME parts and referenced by an ID, so no external request and no encoding bloat. The catch: CID embedding requires your email client to support it at the signature setup stage, and most web-based clients either can't use it or show the image as a stray attachment at the bottom of the email.

What breaks per client

Gmail (web): Strips all style blocks. Rewrites class names. Ignores negative margins. May block base64 images. Handles inline CSS and table layouts correctly.

Outlook (Windows, 2007-2019): Uses the Word rendering engine. No flexbox, no CSS Grid, no float. Partial margin support. Ignores background-image CSS without a VML fallback. Applies the largest padding value in a row to all cells in that row.

Outlook (New Outlook / 365): Newer versions have moved toward a WebKit-based renderer and handle more modern CSS. But many organizations still run older Outlook versions, so you can't assume recipients have the newer client.

Apple Mail: WebKit renderer, broad CSS support. May auto-resize images to fit the window if explicit dimensions are missing. Set width and height as HTML attributes directly on the image tag, not just as CSS.

Yahoo Mail: Strips style blocks similarly to Gmail. Ignores negative padding values.

Mobile clients: Often more forgiving. Media queries work in iOS Mail. Gmail mobile sometimes renders base64 images that Gmail web blocks.

Practical rules for signatures that survive

A few constraints get you most of the way there.

Use table-based layout only. One outer table, cells for avatar and text, inline styles on every element.

Set image dimensions as both HTML attributes and inline CSS. Some clients read attributes; some read the style property. Setting both covers the gap.

Use web-safe fonts with a system fallback. Custom web fonts loaded via an external stylesheet won't display in most email clients. Specifying Arial, Helvetica, sans-serif -- or Georgia, serif -- ensures the signature looks consistent rather than falling back to whatever the client defaults to.

Avoid HTML5 semantic elements. Table, row, cell, paragraph, link, and image are the reliable building blocks. Header, nav, section, and article elements may be ignored or stripped.

Test in real clients -- not browser previews. Browser previews lie. Send the signature to an account you control in Outlook and Gmail before deciding it's done.

When plain text is better

Most of this article assumes you want an HTML signature. Sometimes you don't.

If most of your recipients are in technical or security-conscious roles, HTML signatures look out of place. A two-line plain text signature -- name, title, email, phone -- is faster to read, never breaks, and doesn't make your emails 30-40KB heavier from base64 image data.

If you're in a high-deliverability context, like a cold outreach sequence, a plain text signature can improve inbox placement because it looks more like a personal email.

HTML signatures earn their cost when visual consistency matters: customer-facing roles, branded communications, first-impression emails where you need to convey professional standing at a glance. In long internal reply threads, they're overkill -- and they get uglier with every forward.

Building one without hand-writing HTML

The Z.Tools Email Signature Generator produces table-based HTML with inline styles throughout, which is the structurally sound approach for cross-client compatibility. You fill in your details, pick a template and primary color, optionally upload an avatar, and copy the resulting HTML. Nothing is sent to a server.

The six templates give you different layout structures: Sidebar works well when you have many fields; Minimal is the safest choice when you want to minimize rendering surprises. Social links for Twitter, LinkedIn, GitHub, Instagram, and others are supported.

For the avatar: given Gmail web's inconsistent handling of base64 images, keep the photo small and test in Gmail web directly. If it doesn't render there, removing the avatar is a valid call -- it simplifies the output and eliminates one failure point.

Setup guides for Gmail, Outlook, Apple Mail, and Yahoo are included, since each one handles HTML signature installation differently.

邮件签名生成器

使用可自定义的模板创建专业的电子邮件签名

→

Z.Tools·z.tools

Email Signature Generator · Z.Tools

Create professional email signatures with customizable templates