Email signature line spacing issues trace back to a handful of CSS patterns. Paste your HTML into our free tool and see exactly which rule is the culprit.
The MailSigCraft Team
MailSigCraft
Your signature looks perfect in the editor, then a recipient opens it and sees huge gaps between every line — or the opposite, lines crammed so tight the descenders on "g" and "y" nearly touch the line below. Both symptoms trace back to the same small set of CSS rules, and every mail client interprets those rules a little differently. This post shows exactly which pattern causes which symptom, in which client, and how to fix it — plus a tool that scans your own signature's HTML and flags the specific rule responsible.
Paragraph tags carry a browser default margin that most people never notice until it stacks up across a three- or four-line signature. Replace each <p> with a <div style="margin:0;"> or a single-cell table row, and keep margin:0 on every line you add.
If you set line-height anywhere in your signature, add mso-line-height-rule:exactly; right next to it. Without that pairing, classic Outlook for Windows can substitute its own leading for the value you declared — the single most common reason a signature looks right everywhere except one client.
Two or three <br> tags in a row are a common way to fake vertical space, but each client's default line-box height is different, so the gap ends up a different size in Gmail than in Outlook or Apple Mail. Use one spacer row instead: <div style="height:8px;line-height:8px;font-size:1px;"> </div>.
The editor preview renders in a browser. Outlook desktop, Gmail's app, and Apple Mail don't all use the same rendering engine — send the signature to accounts on at least Gmail, Outlook desktop, and Apple Mail before rolling it out to a whole team.
1 issue found — 1 likely culprit:
<p> tags with no margin reset. Browsers (and Word's rendering engine) give every <p> a 1em top and bottom margin by default — 32px total at a 16px base font size — and nothing here overrides it.
Fix: Replace <p> with <div style="margin:0;"> or a single table row, and keep margin:0 on every line.
This checks your markup for the CSS patterns that most often cause spacing bugs — it doesn’t render your HTML or send it anywhere. All analysis runs in your browser.
Every browser — and, critically, the Word-based rendering engine that classic Outlook for Windows still uses — ships a default stylesheet rule that gives every <p> element a 1em top margin and a 1em bottom margin. At the common 16px base font size, that's 32px of extra vertical space around each paragraph, on top of anything your own CSS specifies. A three-line signature built from three <p> tags can pick up close to 100px of margin nobody asked for, and it reads as "double-spaced" because the visual rhythm between contact lines suddenly doesn't match the rest of the email body.
The fix isn't to fight the margin with a smaller negative value — that behaves inconsistently across clients. Remove the <p> tags entirely and use <div style="margin:0;"> or table rows, which carry no default margin at all.
Classic Outlook for Windows renders HTML through Microsoft Word rather than a browser engine, and Word's own paragraph-leading logic can override a plain line-height declaration with its own default spacing. Microsoft's fix for this is a proprietary CSS extension, mso-line-height-rule:exactly, which tells Word's engine "use the number I gave you, literally" instead of computing its own leading.
This is why a signature can look correctly spaced in Gmail, in Apple Mail, and even in the new WebView2-based Outlook — and still show extra gaps specifically in classic Outlook desktop. If your only symptom is "fine everywhere except one specific Outlook install," this is almost always it.
Add mso-line-height-rule:exactly; immediately after every line-height declaration in your signature's inline styles. It's ignored by every client that doesn't need it, so there's no downside to adding it everywhere.
Using two or three <br> tags in a row to fake a gap between a name block and a contact-info block is common, but it's the least predictable spacer you can use. A line break's rendered height depends on the line-box height of the font at that point in the document — which is exactly the thing that varies between Gmail's rendering, Outlook's Word engine, and Apple Mail's WebKit engine. The same three stacked <br> tags can look like a comfortable gap in one client and a cramped afterthought in another.
Replace stacked <br> tags with a single spacer element that has an explicit pixel height, independent of any font's line-box: <div style="height:8px;line-height:8px;font-size:1px;"> </div>. That renders the same height in every client, because it isn't relying on font metrics at all.
Less common than the double-spacing causes above, but the opposite symptom — text that looks cramped, with the tails on "g," "y," and "p" nearly touching the line beneath — usually traces to a unitless line-height value below 1, like line-height:0.9. That's tighter than the font's own natural line box, so ascenders and descenders on adjacent lines start to overlap. It's most visible in WebKit-based clients like Apple Mail, which render close to the CSS spec with fewer of the extra buffers that Word's engine imposes regardless of what you declare.
Keep line-height at 1.2 or higher for any text block with more than one line. There's rarely a real reason to go below that in a signature — the space saved is a few pixels, and the readability cost is immediate.
Renders line-height and margins exactly as declared, with no special-casing beyond stripping unsupported properties like position or float. If spacing looks wrong here, the cause is in your HTML — not something Gmail is doing to it.
Adds its own paragraph margin around <p> and <div> elements, and can substitute its own leading for a plain line-height unless mso-line-height-rule:exactly sits right next to it.
Chromium-based, so it uses the same default stylesheet as any modern browser. <p> margins and line-height behave exactly as CSS specifies — no mso- hint required, though it's harmless to leave in for the classic client's sake.
<p> tag replaced with a margin:0 block or table row.line-height declared on every text-carrying element — nothing left to a client's default.mso-line-height-rule:exactly sitting next to every line-height declaration.line-height value below 1 anywhere in the markup.Editor previews render in a browser engine, but plenty of recipients — and possibly you, if you're checking in classic Outlook for Windows — read mail through Microsoft Word's rendering engine instead. Word adds its own paragraph margins and can override a plain line-height, neither of which shows up until the HTML actually reaches that engine.
Gmail renders line-height and margins as declared. It strips a handful of unsupported CSS properties (like position and float), but it doesn't impose extra leading or margin logic of its own the way Word-based Outlook does. If spacing looks wrong in Gmail specifically, the rule causing it is in your markup, not in Gmail's renderer.
Something in the 1.2–1.5 range for body text, paired with mso-line-height-rule:exactly. Below 1.2, ascenders and descenders start to crowd each other on multi-line blocks; above roughly 1.6 it starts to look like extra vertical space you didn't intend, especially once it's combined with <p> margins if you haven't removed those too.
Once per line-height declaration — put it directly beside that declaration on the same element, not once globally. Every mail client that doesn't need the hint simply ignores it, so there's no compatibility risk in adding it everywhere you set line-height.
Not reliably. Outlook's built-in signature editor writes its own HTML behind the scenes and doesn't expose a way to add mso-line-height-rule or strip default <p> margins — those are markup-level fixes. Building the signature in a tool that outputs clean, table-based HTML with the fixes already applied (like MailSigCraft's editor) and pasting that in avoids the problem rather than working around it after the fact.
<p> tags break anything else?No — <div> and single-cell table rows carry the same content and support the same inline styles, they just don't come with an unwanted default margin attached. As long as you keep margin:0 explicit on whatever you replace them with, the only change is the spacing bug going away.
Line spacing bugs in email signatures come from a short, specific list of culprits: unstyled <p> tags carrying their default 1em margin, a line-height that Outlook's Word engine is free to override without mso-line-height-rule:exactly, stacked <br> tags used as an inconsistent spacer, or — on the cramped side — a unitless line-height below 1. Fix those four things and test across Gmail, classic Outlook, and Apple Mail, and the "why does this look different in every inbox" problem mostly disappears.
<p> marginline-height value is computed relative to font sizeline-height syntax and unitless vs. percentage behaviorFollows your CSS closely, which is usually a good thing — but that also means a sub-1 unitless line-height compresses tightly enough to visibly clip descenders here, more so than in Word-engine Outlook, which imposes its own minimum leading regardless of what you set.
<br> tags — spacer rows use a fixed-height <div> instead.