How to code an HTML email signature that doesn’t fall apart

Quick answer: To code an HTML email signature, build it as one nested <table> with role="presentation", style everything inline with pixel values, keep it under about 600px wide, use a transparent PNG logo, and test it in the client where it’ll be pasted. Gmail and Outlook rewrite your HTML on the way in, so the editor preview lies.

An HTML email signature looks like the most trivial thing an email developer will ever be handed. It is also, reliably, the most cursed. Here’s why.

It isn’t really an email. It’s an email fragment. You hand a chunk of markup to a compose window, and that window mangles it. Then a recipient’s client re-renders it, and a reply quotes it and re-renders it yet again. Indented. Sometimes with a grey bar down the side. For the rest of its life.

So when someone asks for a “quick HTML email signature,” they’re asking for more than they think. They want markup that stays intact across three rendering surfaces you don’t control. That’s the whole problem in one sentence.

This piece gives you the real table markup and the reason it’s built that way. It covers the deploy gotchas nobody warns you about. And it hands you a testing routine that catches failures before your whole team ships them. No generator funnel. Just the code and the landmines.

Why an HTML email signature is the weirdest thing you’ll code in email

Most email you build, you own. You can test it, can control the template, control the send.

A signature is different. You don’t own it after it leaves your file. You paste it somewhere, and from that moment it belongs to whatever client is holding it.

Think of it less like a web page and more like a sticker you’re mailing to a stranger. You design it carefully and seal the envelope. Then someone else’s hands unwrap it, crease it, and stick it on a surface you’ve never seen. That’s roughly what happens to an HTML email signature between your text editor and your recipient’s screen. Every assumption you can’t verify is a bug waiting to surface.

The three surfaces where a signature lives

Every HTML email signature has to survive three places, and each one breaks it in its own special way.

• Surface one: the sender’s signature settings box. This is where you paste it. Gmail’s box strips half your styling on the way in. Outlook’s box re-encodes the whole thing.
• Surface two: the recipient’s client on first receipt. Now a completely different client renders your markup, maybe on a phone, maybe in dark mode, maybe in classic Outlook.
• Surface three: the quoted reply chain. Someone replies. Your signature gets quoted, indented, wrapped in blockquote styling you never wrote.

Here’s the thing almost every tutorial misses. They only ever check surface one. They paste the signature, glance at the little preview, see it looks fine, and call it done.

That preview is not the signature your recipients see. Not even close.

Design for the worst renderer, then let go

You will not get pixel-identical across all three surfaces. You shouldn’t even try. That way lies madness and a lot of wasted hours.

Build for the worst renderer in the set – classic Outlook, usually – and accept graceful variation everywhere else. Same philosophy that runs through the fluid hybrid approach for full emails. A signature is just that idea shrunk down to something the size of a business card.

The rules, before you write a single tag

There are five rules. Break them and you’ll spend an afternoon wondering why your clean code looks like garbage in one specific client. Follow them and most of the pain never shows up.

Tables, not divs (and no, it isn’t nostalgia)

I know. It’s 2026. We have flexbox and grid and container queries, and reaching for a <table> feels stupid.

But classic Outlook for Windows still renders HTML with Microsoft Word’s engine. That engine does not understand flexbox. It does’t understand grid, ignores margin: 0 auto, it just does whatever Word feels like.

And that engine isn’t gone. Microsoft confirmed classic Outlook stays supported until at least 2029, and it actually pushed the “opt-out” phase – the point where new Outlook becomes the default – back from April 2026 to March 2027. Office 2024 ships the classic client with a five-year support window ending in 2029. So the Word engine is around for years yet. Longer than anyone briefing you on this expects, honestly.

Tables it is. role="presentation" on every one, so screen readers skip the layout scaffolding.

Inline everything, every single style

Signature deploy surfaces strip <style> blocks. The rules for how they strip are badly documented and inconsistent across clients.

So assume this: if a style isn’t inline on the tag, it’s gone.

<!-- Good -->
<div style="font-size:14px; line-height:20px; color:#333333;">...</div>

<!-- Gone the moment Gmail touches it -->
<div class="sig-name">...</div>

No classes. No <style> block. Inline, on the element, always.

Pixels only, nothing clever

Use px. One unit. Fixed widths.

Skip rem, em, %, vw, all of it. This is a small, fixed artefact that has to look the same everywhere. Clever units introduce variables you don’t need and can’t fully test. Keep it boring on purpose.

Keep the whole thing under 600px

An HTML email signature has to fit inside a quoted reply on a phone without forcing horizontal scroll. That’s the constraint that decides your width.

Six hundred pixels is the ceiling. Narrower is safer. A compact fixed-width table beats a wide one every time, because it survives being crammed into an indented reply.

Add mso-line-height-rule before every line-height

This one bites everyone exactly once, and then never again because you never forget it.

Classic Outlook invents its own line spacing unless you tell it not to. The fix is one declaration, inline, before your line-height:

<div style="mso-line-height-rule:exactly; line-height:20px; font-size:14px;">

Without mso-line-height-rule:exactly, your tidy 20px lines turn into whatever Outlook decides. With it, they behave.

The actual HTML email signature code you can steal

Right, the markup. This is the part people copy, so it’s correct and it’s minimal. No mystery   spam, no leftover generator cruft, nothing you have to reverse-engineer later.

The skeleton

One role="presentation" table. Two cells. Logo on the left, details on the right. That’s the entire structure of a clean HTML email signature.

<!-- HTML email signature: one presentation table, inline styles, fixed width -->
<table role="presentation" cellpadding="0" cellspacing="0" border="0"
       style="border-collapse:collapse; border:0;">
  <tr>
    <!-- Logo cell -->
    <td style="padding:0 16px 0 0; vertical-align:top;">
      <img src="https://yourdomain.com/sig/logo.png"
           width="120" height="120" alt="Acme Co logo"
           style="display:block; border:0; width:120px; height:120px;">
    </td>
    <!-- Details cell -->
    <td style="vertical-align:top;
               font-family:Arial, Helvetica, sans-serif;">
      <div style="mso-line-height-rule:exactly; font-size:16px;
                  line-height:20px; font-weight:bold; color:#333333;">
        Jordan Lee
      </div>
      <div style="mso-line-height-rule:exactly; font-size:14px;
                  line-height:18px; color:#555555; padding-top:2px;">
        Head of Growth, Acme Co
      </div>
      <div style="mso-line-height-rule:exactly; font-size:14px;
                  line-height:18px; color:#555555; padding-top:8px;">
        <a href="tel:+15551234567"
           style="color:#555555; text-decoration:none;">+1 555 123 4567</a>
      </div>
      <div style="mso-line-height-rule:exactly; font-size:14px;
                  line-height:18px; padding-top:2px;">
        <a href="https://acme.co"
           style="color:#1a73e8; text-decoration:none;">acme.co</a>
      </div>
    </td>
  </tr>
</table>

Copy it, swap the values, and you’ve got a working base. Everything below explains why each line is there.

The logo cell

Note the <img> has width and height as attributes, not just CSS.

That’s deliberate. Outlook ignores CSS dimensions on images often enough to matter. The old HTML attributes still work when the CSS doesn’t. So you set both, belt and braces.

display:block kills the phantom gap that appears under inline images. border:0 stops some clients drawing a link border around a linked logo. And alt text matters here more than usual, which I’ll get to in the dark-mode and machine-readability sections.

The details cell

Name, title, company, phone, links. All of it live text. Never an image of text.

This is non-negotiable, and there are three reasons.

1. Image-only signatures are uncopyable. Nobody can grab your phone number to dial it.
2. Some clients block images by default. Your whole signature becomes a broken-image icon.
3. The AI summarisers can’t read images. Gemini in Gmail and Apple Intelligence read live text only. More on that near the end, because it’s becoming a bigger deal than most people notice.

So type the text. Style it inline. Don’t flatten it into a picture, however tempting the perfect kerning looks.

Links, and the phone-number-turns-blue gotcha

You’ll have seen this one. Your carefully styled phone number shows up blue and underlined on iOS, ignoring every colour you set.

That’s iOS auto-linking the number into a tel: link and applying its own styling. The fix is to wrap the number yourself and force the colour:

<a href="tel:+15551234567"
   style="color:#555555; text-decoration:none;">+1 555 123 4567</a>

By linking it deliberately and styling that link, you win. The client leaves your version alone. Same trick works for addresses that get auto-linked into map links.

Spacing without margins

Outlook desktop drops margin on divs and images. It’s inconsistent about padding too. So don’t rely on either for layout.

Put your spacing on the <td>. Pad the cell, not the element inside it. That’s why the skeleton uses padding on the table cells and padding-top on the divs rather than margins anywhere.

Need horizontal space between two blocks? Add a narrow spacer <td> between them – a ghost column with a fixed width. Ugly, but it’s the thing that holds across clients.

Social media icons, without the bloat

Most people want a row of little social icons. Fine. Just don’t let them wreck the signature.

Each icon is its own small hosted PNG, wrapped in a link, sat in its own <td>. Keep them in a single row inside a nested table so the spacing stays predictable.

<table role="presentation" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td style="padding-right:8px;">
      <a href="https://linkedin.com/company/acme">
        <img src="https://yourdomain.com/sig/li.png" width="20" height="20"
             alt="LinkedIn" style="display:block; border:0;">
      </a>
    </td>
    <td style="padding-right:8px;">
      <a href="https://x.com/acme">
        <img src="https://yourdomain.com/sig/x.png" width="20" height="20"
             alt="X" style="display:block; border:0;">
      </a>
    </td>
  </tr>
</table>

Two rules keep social icons from becoming a problem. Keep each icon around 20 to 24px, and keep the whole row to three or four icons max. Every extra icon is another hosted request on every email. It’s also one more thing that 404s when someone moves a file. Small, few, hosted. That’s the recipe.

Watch the dark-mode trap here too. A dark monochrome icon set vanishes on a dark background, exactly like a dark logo does. Midtone grey icons survive far better than pure black ones.

Images in a signature – the part that quietly ruins everything

Text you can mostly control. Images are where a clean HTML email signature quietly falls apart. Usually in ways you don’t spot until a recipient tells you.

Host them, do not embed them

Base64-embedding your logo feels clever. It seems self-contained, no external request, no broken link.

Don’t. Reply chains bloat every time the embedded image gets re-encoded. Some clients strip base64 entirely. CID embedding has its own mess.

Host the image on a real URL instead. A plain https:// link to a file on your server or CDN. This overlaps heavily with image optimization for email, which goes deeper on compression, hosting and alt text. Worth a read if images are your recurring pain.

Size and weight

A signature logo wants to sit around 100 to 200px on its longest edge. Export at 2x for retina screens. Then constrain it with width and height attributes so it displays at the intended size.

Keep the file small. This image ships on every single email the person sends. Ten emails a day, a hundred employees, and a lazy 400KB logo turns into real bandwidth and real load time. Compress it. A tidy PNG here is usually well under 30KB.

The transparent-PNG trap

A transparent PNG is the right call. But there are two traps hiding inside that sentence.

Trap one: the JPEG glow. A JPEG can’t hold transparency. So a JPEG logo on a dark client renders your logo plus a glowing white rectangle around it. This is, hands down, the single most-reported signature bug I see. The fix is one word: PNG. Specifically PNG-24 with a properly transparent background. Never JPEG.

Trap two: dark linework vanishing. A transparent PNG solves the white box. But if your logo is dark lines on transparency, it disappears on a dark background. Now you’ve got the opposite problem.

The real fix for trap two lives in the dark-mode section: keep a light version of the logo too.

The circular-headshot trick

If the signature includes a headshot, mask it to a circle with transparent corners.

Why bother? A circle has no straight edge for the dark-mode glow to catch. A square photo on a dark background can pick up a faint halo at the corners. A circular crop dodges it entirely. Cheap, quick, and it happens to look intentional and polished. Everybody wins.

One extra wrinkle for classic Outlook. Word’s engine ignores border-radius, so a CSS-rounded image shows up square there. If a round shape really matters, bake the circle into the PNG itself with transparent corners. Don’t rely on rounding it in CSS. Some developers layer a VML fallback to round the image in Outlook specifically, but for a signature that’s usually overkill. Pre-masked PNG is simpler and it works everywhere at once.

Making the HTML email signature survive dark mode

This section overlaps hugely with the full dark mode email guide. I’ll summarise the signature-specific bits here and point you there for the deep dive. No sense writing that whole article twice.

Three clients, three completely different moods

There is no single dark-mode fix, because the major clients each behave differently. Say it in one breath:

• Apple Mail inverts aggressively. It’ll flip your colours whether you asked or not.
• Classic Outlook desktop barely touches it. Your light signature mostly stays light.
• Gmail partially inverts some palettes. Selective, unpredictable, palette-dependent.

So you can’t “turn on dark mode” for a signature. You can only make defensive choices that hold up across all three.

Midtone colours that dodge inversion

Here’s a trick worth knowing. Partial-invert clients tend to leave midtone colours roughly alone.

Backgrounds around #CCCCCC and darker, text around #333333 and lighter – those often survive untouched. Pure #FFFFFF and pure #000000 are the ones clients love to flip.

So build your HTML email signature in that midtone band instead of the extremes. Do that and roughly half your inversion surprises just evaporate. It’s the highest-value, lowest-effort dark-mode move for a signature.

The two-logo swap

You can serve a different logo in dark mode with <picture> and prefers-color-scheme:

<picture>
  <source srcset="https://yourdomain.com/sig/logo-light.png"
          media="(prefers-color-scheme: dark)">
  <img src="https://yourdomain.com/sig/logo-dark.png"
       width="120" height="120" alt="Acme Co logo"
       style="display:block; border:0;">
</picture>

Honest caveat: Gmail ignores this. So does classic Outlook. Treat it as progressive enhancement, not a guarantee.

So your default file – the src on the <img> – still has to read on both light and dark backgrounds. The swap is a bonus for clients that support it, not your safety net.

The numbers, so you stop skipping this

People love to skip dark mode. “I’ll just do light, it’s fine.” It is not fine, and here’s why in plain numbers.

Roughly a third of the people opening your mail are in dark mode. Apple Mail alone, which inverts hard, is more than half of all opens. And barely one in ten of us actually designs for it, which is the whole reason so many signatures fall over the second the palette flips. Skipping dark mode means breaking your signature for the majority of your audience. Those aren’t edge cases. That’s the default now.

Deploying it – where your clean code goes to die

This is the part every generator page skips. They stop at “paste and save.” That’s exactly where the real trouble starts.

Gmail will not take raw HTML

You cannot paste <table> markup into Gmail’s signature box. It won’t render it, it’ll show you the tags.

The workaround goes like this. Open your coded HTML email signature in a browser. Select the rendered result – the visible signature, not the code – and copy it. Then paste that into Settings, General, Signature.

Gmail keeps a mangled subset of the inline styling and silently drops the rest. Some spacing goes. Some colours survive. It’s inconsistent. So after you paste, send yourself a real email and check the actual result, not the settings-box preview.

Outlook will take raw HTML, then argue about it

Outlook is one of the few places that’s easier than Gmail here. You can paste raw HTML, or edit the signature file on disk directly.

But classic and new Outlook render the result differently. And Outlook on the web adds its own top and bottom table padding when you save. So “it worked in one Outlook” tells you nothing about the others.

Here’s a real, recent example of why you re-test after every update, not once. In December 2025, classic Outlook’s Version 2512 (build 19530.20038, shipped 16 December) suddenly forced visible borders onto signature tables. It didn’t matter what your markup said. Word’s engine started applying a non-zero border, and thousands of clean signatures grew ugly lines overnight. Microsoft fixed it with a service-side change in the Version 2601 build in early February 2026.

Nobody changed their code. An Outlook update changed it for them. That’s the entire argument for testing after every Outlook build, not just at launch.

The deploy surface rewrites your HTML

Read this twice, because it’s the thing that gets people. The signature you QA’d is not necessarily the signature that ships.

The settings box strips, reorders, and re-encodes your markup on save. What comes out the other side can differ from what you pasted in.

So there’s exactly one reliable test. Send yourself a real email from the deployed signature. Not from your source file. From the actual signature sitting in the actual client, after the settings box has had its way with it.

A common casualty here is character encoding. Curly apostrophes, accented names, the odd em dash – deploy surfaces sometimes re-encode them into garbage like ’. If your source file uses fancy typographic characters, the settings box may not carry them cleanly. Keep the text in your HTML email signature plain and UTF-8, and eyeball every accented name in the deployed send. It’s a five-second check that saves an embarrassing “Renée” turning into “Renée” in front of a client.

Team rollout, briefly

If this is for one person, the settings-box route is fine. If it’s a whole company, per-person pasting doesn’t scale and consistency drifts fast.

At that point you’re into signature-management platforms – Exclaimer, Crossware, that category. They centralise deployment and keep everyone consistent. I’ll flag them, not sell them. My lane is the code that goes inside those tools, not the SaaS wrapping around it.

Testing a signature, and why the editor lied to you

The settings-box preview showed you a fine signature. Then it broke in the wild. That gap is the whole reason this section exists.

The test order that catches the most, fastest

You don’t need to check forty clients for a signature. You need the right four, in the right order, because some expose more failures than others.

1. Apple Mail on iOS, dark mode. Partial inversion here surfaces most colour and transparency failures first.
2. Classic Outlook Windows, dark theme. The Word engine’s quirks show up, plus any border surprises.
3. Outlook 365 web, dark account. Catches the save-time padding and the new-Outlook rendering.
4. A Gmail reply chain. The surface most recipients end up seeing.

Run those four and you’ve caught the large majority of real bugs. Everything past that is polish.

The reply-chain check nobody does

This is the single most skipped test. It’s the surface most recipients look at.

Send the signature to yourself. Then reply to your own email and look at how the signature renders quoted and indented. Do it in light mode and dark mode both.

That quoted, indented render is what a recipient sees on every back-and-forth after the first. Editors never show you this view. Which is exactly why so many “working” signatures fall apart mid-conversation.

Tools and current pricing, no fluff

Let’s talk cost, because it’s changed and old tutorials are wrong now.

• Litmus Core runs about $500 per month, roughly $4,980 billed annually. Validity acquired Litmus in April 2025 and restructured pricing that August. The old cheap Basic tier is gone. That’s a lot for a single signature.
• Email on Acid sits around $73 per month billed annually and covers most solo needs comfortably.
• Putsmail is gone. If a tutorial still recommends it, treat the whole tutorial as stale and move on.

Honest take for signatures specifically: a small real-device lab beats all of them. An old iPhone, an Android handset, a Mac, a Windows box with classic Outlook. A signature is tiny. You can eyeball it live, in dark mode, in a real reply, in seconds. For a one-off signature, $500 a month makes no sense. Buy the cheap phones.

A quick note on Apple’s Mail Privacy Protection

One footnote so nobody panics. Apple’s Mail Privacy Protection pre-fetches your hosted logo automatically.

That means your open-rate numbers include machine loads, not just humans. It’s not a signature bug, and there’s nothing to fix. Just don’t be alarmed when your signature logo shows a wild open count. That’s MPP loading the image, not a hundred people staring at your face.

Where signatures are heading – the inbox that reads itself

Almost no signature guide talks about this, which is exactly why it matters. The inbox is starting to read your mail before the human does.

Gemini in Gmail and Apple Intelligence in Apple Mail now summarise messages. And the summary engines read live text only. They ignore images, alt text and emoji.

So picture a signature built as one flat image. To the machine increasingly deciding whether your email is worth opening, that signature is invisible. It contributes nothing to the summary. It might as well not exist.

Live-text signatures used to be an accessibility nicety. They still are, which is why accessible HTML emails and signatures share so much DNA. But now they’re also machine-readability. The signature that reads as real text is the one the AI can read.

The Word engine is finally leaving; classic Outlook support ends no earlier than 2029. That will ease the layout pain eventually. It won’t touch the deploy-surface mangling. It won’t touch dark-mode inversion. Those are here for the long haul. So the honest expectation is: signatures get a little easier, not easy.

Here’s a prediction I’ll stand behind. By 2030, the winning HTML email signature reads perfectly as plain text and renders cleanly as HTML. And it survives being quoted. Not the one with the animated logo. Boring, robust, and readable by both humans and machines. That’s the whole direction of travel.

There’s a small irony in all this. The “best practices 2026” advice for a signature is nearly identical to the advice from a decade ago. Tables, inline styles, small hosted images, live text. The tooling around email keeps changing. The dumb, durable core of a good HTML email signature barely moves. Which is oddly reassuring – learn it once, and it stays learned for years.

The short version

If you skimmed everything above, here’s the entire game in one box.

• Table-based. Inline-styled. Pixel widths. Under 600px.
• Transparent PNG logo. Never JPEG.
• Live text. Never an image of text.
• Midtone colours to dodge dark-mode inversion.
• Test the deployed signature in a real reply chain, not the editor.

And if you’re briefing someone else to build your HTML email signature, ask them two questions. Did you test it quoted inside a reply? And what does it look like the moment dark mode turns on? If they only ever checked the settings-box preview, they didn’t test it. They looked at it.

If you need a signature that holds together in Outlook for as long as Outlook exists, that’s the work. And it’s the work I do. Send a brief, get a same-day reply, and see the cross-client test results before it reaches your team. That includes the reply-chain pass and the dark-mode pass, because those are the two everybody else skips.

Two pieces are still coming that this article keeps pointing at: the container-queries deep dive, and the full dark-mode breakdown. Subscribe if you want them when they land.

Frequently asked questions

Do I need to code an HTML email signature by hand, or is a generator fine?

A generator is fine for a plain one-logo, one-line signature, and it’ll save you an afternoon. Hand-coding wins the moment you need brand-exact spacing or a dark-mode logo swap. It also wins when the signature must survive Outlook and reply chains without a monthly SaaS bill. Generators optimise for “done,” not for “correct in classic Outlook.”

Why does my email signature look broken in Outlook?

Almost always because classic Outlook for Windows renders with Microsoft Word’s engine. That engine ignores modern CSS, drops margins and padding, and can add its own borders after an update. Rebuild with a role="presentation" table, inline styles, padding on the <td> instead of the element, and mso-line-height-rule:exactly on every line-height.

Why does my logo have a white box around it in dark mode?

Because it’s a JPEG, or a PNG saved with a white background. JPEGs can’t be transparent, so a dark client renders the logo plus a glowing white rectangle. Re-export as a PNG-24 with a genuinely transparent background. If the logo is dark linework, make a light version for dark backgrounds too.

How do I add an HTML signature to Gmail?

You can’t paste raw HTML into Gmail’s signature box. Open your coded signature in a browser, select and copy the rendered result, then paste that into Settings, General, Signature. Gmail keeps a subset of the inline styling and drops the rest, so send yourself a real test afterwards.

Can I paste raw HTML into Outlook’s signature?

Yes – via the signature settings box or by editing the signature file directly. That’s one of the few things Outlook makes easier than Gmail. But classic and new Outlook render differently, and Outlook on the web adds padding on save. Verify the output in each Outlook you care about.

What image format should an email signature logo use?

PNG-24 with a transparent background, hosted on a real URL. Size it around 100 to 200px on its longest edge. Constrain it with width and height attributes on the <img>. Avoid JPEG, which has no transparency and glows in dark mode. Avoid base64-embedding, which gets stripped or bloats reply chains.

How wide should an HTML email signature be?

Keep it at or under 600px, and narrower is safer. It has to fit inside a quoted reply on a phone without forcing horizontal scroll. A compact fixed-width table beats a full-width one every single time.

Do email signatures need to be responsive?

Not with media queries, usually. The deploy surfaces strip <style> blocks, so media queries often don’t survive anyway. A single narrow fixed-width table that already fits a phone screen is the reliable “responsive” approach for signatures. Stacking columns on mobile is a nice-to-have, not load-bearing.

Why does my signature break when someone replies?

Because the reply chain re-renders your signature quoted and indented. Sometimes it adds blockquote styling, in whatever client the recipient uses. Test by replying to your own test send and checking the quoted render in light and dark mode. It’s the surface most recipients see, and the one editors never preview.

Is it worth using Litmus just for a signature?

Probably not for a one-off. Litmus Core is around $500 per month now, which is a lot for a single signature. For signatures specifically, a small real-device lab wins. That’s an old iPhone, an Android phone, a Mac, and a Windows box with classic Outlook. It catches more, faster, because the artefact is tiny and you can inspect it live.