Why email signatures balloon in file size, the exact math behind base64 inflation, and a live calculator that tells you if your signature is safe, heavy, or about to get clipped.
The MailSigCraft Team
MailSigCraft
Your signature looked fine in the editor, then Gmail cut the message short with a "[Message clipped] View entire message" link, or your Sent folder started eating storage faster than it used to. Both trace back to the same root cause: the total file size of your signature's images, not just one banner's dimensions, crossed a threshold somewhere between your outbox and the recipient's inbox. This post gives you the per-element weight budget and a live checker that adds it up before you find out the hard way.
A signature's total weight is the sum of every image in it — logo, banner, headshot, and each social icon — plus the HTML table markup and inline CSS that wraps them. A guide focused only on banner pixel dimensions misses that five 3KB social icons add up to the same weight as one 15KB image, and most signatures ship both a banner and an icon row.
A base64-embedded image is encoded as text and lives inside your signature's HTML — its weight always counts toward Gmail's clip threshold. A hosted image is just a URL; the mail client fetches it separately, and the URL itself is only a few dozen bytes. Hosting costs you one HTTP request per image at read time; embedding costs you permanent HTML weight on every single email you send.
Base64 encoding is defined by RFC 4648 as 4 output characters for every 3 input bytes — a fixed one-third size increase. A 15KB PNG becomes a 20KB text blob inside your HTML the moment you embed it. There's no compression setting that avoids this; it's how the encoding works.
Gmail enforces two separate, unrelated limits: a 10,000-character limit on the signature you save in Settings, and a roughly 102KB total-HTML threshold that clips the sent message if you cross it — almost always from base64-embedded images. Run your numbers through the calculator below before you find out which one you hit.
Well clear of Gmail's clip threshold, even with markup overhead added in.
0KB — 102KB (Gmail’s message-clip threshold)
Estimates only — actual weight also depends on your mail client’s own MIME encoding and any signature disclaimer text. Toggle an element to hosted to see it drop out of the HTML total entirely.
The file size you see in your image editor is not the size that ships. A 20KB PNG logo becomes roughly 27KB of base64 text once embedded, and that 27KB is now permanent HTML weight on every email that signature goes out on. Most people budget against the original file size and never account for the encoding overhead, which is exactly how a signature that "looked fine" turns out to be the thing that got clipped.
A single 20KB banner reads as manageable. Five social icons at 3KB each is the same 15KB raw weight — but people routinely add a banner, a logo, a headshot, and 5–6 icons to the same signature without ever summing them. Run the numbers: logo (8KB) + banner (20KB) + headshot (12KB) + five 3KB icons (15KB) is 55KB raw before encoding, and base64 embedding all of it pushes that to roughly 73KB of HTML — inside caution range even before your name, title, and disclaimer text are counted.
Email-safe HTML uses nested <table> layouts with inline styles on nearly every cell, because that's what survives Outlook's Word rendering engine and Gmail's CSS stripping. Each social icon typically needs its own <td>, <a>, and <img> with explicit width/height attributes — call it 150–300 bytes of markup per icon before the image data is even counted. Across a six-column signature table, that overhead alone can add a kilobyte or two that never shows up in any "file size" you check for an individual image.
Gmail's ~102KB threshold clips a single message. Outlook and Exchange don't clip signatures the same way, but they don't forget them either: HTML email is structured as a multipart/related container per RFC 2557, which means every embedded image ships as a full, non-deduplicated copy inside each individual message. Send 1,000 emails a month with a 40KB embedded signature and that's roughly 39MB added to your Sent Items every month — a slow mailbox-storage leak that a hosted signature never creates, since hosted images are just a link repeated 1,000 times.
A hosted image adds zero KB to your signature's HTML, but it does add a runtime dependency: the recipient's client has to successfully fetch that URL. A broken link, an expired CDN path, or a corporate proxy blocking the domain shows a broken-image icon instead of a clipped message — a different failure mode, not a strictly better one. MailSigCraft's editor defaults to CDN-hosted HTTPS images for this tradeoff specifically, because a reliable, always-on CDN link beats both failure modes in practice.
Adds its full (inflated) weight to your signature's HTML on every send. Counts toward Gmail's ~102KB clip and toward the Sent Items storage that Outlook/Exchange accumulate over time. No extra network request needed to display it.
Adds only the URL's byte length to your HTML — effectively free against Gmail's clip threshold. Costs one HTTP request per image at read time and depends on the host staying reachable to the recipient's client.
Keep the embedded (base64) portion of your signature's HTML under roughly 50KB, and you're comfortably clear of Gmail's ~102KB clip threshold even after your name, title, and disclaimer text are added. Anything hosted by URL doesn't count toward that number at all.
Not directly — spam filters weigh sender reputation and authentication (SPF/DKIM/DMARC), not signature file size. The real costs are a clipped message in Gmail, a slower-loading email for the recipient, and, for high-volume senders, Sent Items storage that grows faster than it needs to.
Two things the editor's preview doesn't surface: base64 encoding adds a fixed 33% to every embedded image's byte count, and the table markup wrapping each element adds its own overhead. Neither shows up when you're just eyeballing a single image file's size.
Host it, if you have a reliable CDN or the option your signature tool provides. Embedding trades a small reliability risk (the image is always "attached," nothing to fetch) for permanent HTML weight added to every email you send. For anyone sending regularly, hosting wins on total cost.
There's no hard cap, but each icon adds both its base64-inflated weight and its own markup overhead. Five to six small (2–3KB) icons, hosted, add almost nothing. The same six icons embedded add up to 15–24KB before inflation — worth hosting if you're already close to Gmail's clip threshold from a logo or banner.
Not the same mechanism. Outlook and Exchange don't clip a message the way Gmail does, but every embedded image ships as a full, non-deduplicated copy inside each sent message's multipart/related container — so a heavy signature compounds into Sent Items storage over time rather than clipping any single email.
A signature's file size is the sum of every image in it, inflated by a fixed 33% if you embed rather than host, plus a small but real markup overhead — not just the size of your biggest banner. Add up the whole signature, host what you can, and check the running total against Gmail's ~102KB clip threshold before you find out about it from a recipient instead.
multipart/related structure that carries inline images in each individual message