Email signature HTML quirks in Gmail and how to work around them
Gmail’s HTML email composer is a time capsule. It still renders tables, inline styles, and margin: 0 hacks from 2012, but it also aggressively rewrites your markup the moment you paste it into the signature editor. The result: your carefully crafted signature breaks, links lose their tracking parameters, and images mysteriously gain extra padding.
The core problem is that Gmail does not store your signature as raw HTML. It stores a sanitized, MIME-encoded version that strips certain tags, rewrites URLs, and injects its own inline styles. When you reply or forward, Gmail re-parses that stored HTML, and any quirk in the original paste becomes a permanent bug.
Here are the specific Gmail signature HTML bugs we see most often, and the exact workarounds that survive the paste-and-send gauntlet.
The margin: 0 reset that never sticks
Gmail’s composer wraps your signature in a <div> with its own default margins. If you try to reset those margins with a global CSS rule like div { margin: 0; }, Gmail strips it. It only respects inline styles on the exact element you target.
The fix is to apply style="margin: 0; padding: 0;" directly to your outermost table or <div>. Do not rely on a <style> block in the <head> — Gmail ignores <style> tags in signatures entirely. It also strips class attributes, so any CSS you write in a <style> tag is dead on arrival.
Workaround pattern:
<table role="presentation" cellpadding="0" cellspacing="0" border="0" style="margin: 0; padding: 0; border-collapse: collapse;">
That role="presentation" attribute is not decorative. Gmail’s accessibility parser uses it to decide whether to strip your table. Without it, Gmail may wrap your table in a <div> with display: block, which adds vertical whitespace above and below your signature.
The cellpadding and cellspacing ghost spacing
Gmail’s composer has a habit of injecting cellspacing="0" cellpadding="0" into your tables — but only sometimes. If you paste a signature that lacks these attributes, Gmail may add default spacing of 2px or more between table cells, creating invisible gaps that break your layout.
The bug appears when you edit a signature in Gmail’s settings, save it, and then open a compose window. Gmail re-serializes the HTML and may add cellspacing="1" or similar if it detects a nested table without explicit attributes.
The fix: Always set cellpadding="0" cellspacing="0" border="0" on every single table, including nested ones. If you have a two-column layout (avatar on the left, text on the right), both the outer and inner tables need these attributes. Gmail will not add spacing if the attributes are already present.
Image padding and the display: block trap
Gmail adds 4px of padding below any <img> tag that is not explicitly set to display: block. This is the single most common signature bug we see. Your logo looks fine in the editor, but in the sent email, there is a gap between the image and the text below it.
The workaround is twofold:
- Add
style="display: block; border: 0; outline: none; text-decoration: none;"to every image. - Wrap the image in a
<a>tag with the same inline styles, even if the image is not a link. Gmail sometimes wraps images in its own anchor tag for tracking, and if your image already hasdisplay: block, the wrapper does not add extra space.
A second image bug: Gmail rewrites image URLs to go through its proxy (google.com/s2/favicons or ci3.googleusercontent.com). If your image URL contains query parameters, Gmail may strip them. If you are using a tracking pixel in your signature, this breaks it. The workaround is to use a short redirect URL for the image, not a direct CDN link with parameters.
The font-family fallback that Gmail ignores
Gmail’s composer defaults to Arial, Helvetica, sans-serif for any text that does not have an explicit font-family. If you set font-family: 'Helvetica Neue', Arial, sans-serif; on a <td>, Gmail usually respects it — but only if the font name is in quotes and the fallback list is complete.
The bug appears when you use a font that Gmail does not recognize, like Inter or Roboto. Gmail strips the entire font-family declaration if it cannot find a match in its whitelist. The result is that your signature renders in Arial, regardless of what you specified.
The workaround: Always include a generic fallback. Use font-family: 'Inter', Arial, sans-serif; — not font-family: 'Inter';. Gmail’s parser checks the entire list, and if it sees a generic family at the end, it keeps the declaration. If you omit the generic fallback, Gmail treats the whole thing as invalid and drops it.
Link tracking parameters get stripped on reply
This is the one that hurts marketers. You build a signature with a link like https://example.com/?utm_source=signature&utm_medium=email&utm_campaign=launch. You paste it into Gmail’s signature editor. It works on the first send.
Then you reply to a thread. Gmail re-wraps your signature in a <blockquote> or a <div> with class="gmail_quote". During that re-wrap, Gmail’s URL sanitizer strips any query parameter it considers "tracking-like" — specifically utm_*, fbclid, gclid, and mc_cid.
The workaround: Do not put UTM parameters directly in the signature HTML. Instead, use a redirect URL. For example, link to https://yourdomain.com/sig/launch and have that endpoint issue a 302 redirect to the full URL with UTM parameters. Gmail’s sanitizer only checks the href it sees, which is clean. The redirect happens after the email is sent, so the tracking parameters survive.
If you cannot use a redirect, the fallback is to use a URL shortener like bit.ly or t.co. Gmail does not strip shortener domains because it cannot know the target URL. But shorteners add latency and are less trustworthy for click tracking.
The line-height collapse in Outlook and Gmail
Gmail and Outlook have opposite defaults for line-height. Gmail uses normal (about 1.2), Outlook uses 1.0. If you set line-height: 1.5 on a <td>, Gmail respects it, but Outlook will override it unless you also set it on the <table> and the <div> that wraps the signature.
The bug manifests as text that looks cramped in Gmail but overly spaced in Outlook. The fix is to set line-height on every block-level element in your signature: the outer table, each <td>, and any <p> or <div> tags.
A more subtle variant: Gmail’s composer adds line-height: 1.2 to the <div> that wraps your signature when you save it. If your signature has a line-height of 1.4 on a <td>, Gmail’s wrapper <div> overrides it because the wrapper has higher specificity in the cascade. The workaround is to set line-height on the outermost element of your signature HTML, not on inner elements.
Nested tables and the width: 100% bug
Gmail’s composer sometimes collapses nested tables that have width: 100%. If your signature has a two-column layout where the left column is a fixed-width image and the right column is fluid text, Gmail may force the right column to 100% width, pushing the image to its own line.
This happens because Gmail strips max-width and min-width declarations. If your inner table has style="width: 100%; max-width: 400px;", Gmail removes the max-width and leaves width: 100%, which breaks the layout.
The workaround: Use fixed pixel widths on inner tables. Set style="width: 400px;" on the inner table, not width: 100%. If you need responsiveness, use style="width: 100%; max-width: 400px;" on the outer table only, and keep inner tables at fixed widths. Gmail will not strip max-width from the outer table because it does not re-wrap that element.
How newmail.click handles this
We built newmail.click to generate signatures that pass Gmail’s parser on the first try. The free builder outputs HTML with inline styles, role="presentation" on every table, and explicit cellpadding/cellspacing attributes. It also strips UTM parameters from visible links and replaces them with a redirect URL that preserves your tracking data. The Pro tier adds click and open tracking via a transparent pixel and a link wrapper, with Slack or email alerts on engagement. UTM defaults are applied at the redirect layer, not in the signature HTML, so Gmail’s sanitizer never sees them. If you paste a newmail.click signature into Gmail, it renders correctly on first send and on every reply after that.
The hard truth is that Gmail’s signature editor is not a WYSIWYG tool — it is a sanitizer with a text box. Every workaround above is a direct response to a specific parser rule, and the rules change without notice. The only reliable strategy is to generate signatures that pre-empt the parser, not fight it after the fact.