The right email signature banner size for Gmail, Outlook, and Apple Mail — plus why base64-inlined banners trigger Gmail's '[Message clipped]' link.
The MailSigCraft Team
MailSigCraft
A banner that looks crisp in your editor can arrive blurry, stretched, or completely missing once it lands in someone's inbox — and if you embedded it directly in the HTML, it can even truncate your whole signature behind a "[Message clipped]" link. None of that is random. It comes down to three numbers: display size, export density, and payload size. This post gives you the exact math for each, plus an interactive calculator that checks your banner before you ship it.
Decide how wide the banner actually renders inside the signature table — not the size of the source file. MailSigCraft's own banner uploader suggests 600×100px as a starting point for the drop zone, matching the industry-standard ~600px safe width that keeps HTML email bodies from triggering horizontal scroll in Gmail's and Outlook's default reading panes. Wider source images get resized down to fit, so this is the number to design around.
Every image with a scale factor above 1.0 is what Apple's Human Interface Guidelines call a high-resolution asset — a 2x (Retina) image doubles the pixel count of a 1x image in both dimensions, and a 3x image triples it. A 600×100px display slot needs a 1200×200px source file to look sharp on a Retina or Super Retina display; export at 1x and it reads as soft or pixelated the moment it's viewed on any modern phone or laptop screen.
Outlook for Windows (2007 through Microsoft 365 classic) still renders HTML email through the Word engine, not a browser engine, and Word largely ignores CSS width/height on images. It does respect the HTML width and height attributes on the <img> tag directly — so those attributes are your master override for Outlook, on top of matching CSS for every other client.
A hosted banner (an actual URL Outlook, Gmail, and Apple Mail fetch over HTTP) never counts toward Gmail's HTML-size clip. A base64-inlined banner is embedded directly as text inside the HTML, so its encoded size is added straight to your message's total. If you're inlining, budget for it — base64 encoding is defined by RFC 4648 as 4 output characters for every 3 input bytes, a fixed one-third size increase with no way around it.
Export this
1000×200px, ~96KB once base64-encoded
Close to Gmail's ~102KB clip threshold once the rest of your signature HTML is added. Consider a hosted URL for headroom.
Estimate only: file size is assumed to scale with total pixel count (density²) at a fixed compression quality. Hosted images don't count toward Gmail's HTML-size clip at all — only what's inlined as base64 does.
MailSigCraft — like most signature generators — stores banner uploads as base64 data URIs so the image survives save/reload without needing a hosting endpoint. That convenience has a cost: a 500×100px banner exported at 2x with a modest 18KB (1x-equivalent) compressed size becomes roughly 72KB once scaled for the extra pixels, then roughly 96KB again once base64-encoded — a hair under Gmail's ~102KB total-HTML clip, before your name, title, phone number, and social icons are even added to the count. Go to 3x density on the same banner and the base64 payload alone crosses 200KB, guaranteeing a clipped message. This is exactly why the interactive calculator above treats "inline" and "hosted" as separate cases.
Outlook's Word-based rendering path was built to unify email composition with document authoring, not to implement the CSS box model. Microsoft has continued shipping it in classic Outlook for Windows even as the new, browser-engine-based Outlook rolls out to more users through 2026. Until every recipient is migrated, a banner with only a CSS width can render at its full native pixel size in Outlook — often several times larger than intended — because Word has nothing else to size it by.
Outlook for Windows, running the Word engine, has never supported SVG in HTML email — it either shows a broken-image icon or drops the element outright. Microsoft has also begun retiring inline SVG support in the new Outlook for Windows and Outlook on the web for security reasons, so SVG is now a shrinking target across every Outlook surface, not just classic. Export banners as PNG or JPEG; save SVG for icons you control entirely on your own website.
Set width without height (or vice versa) and most clients scale the missing dimension to preserve the source file's native aspect ratio — which only matches your display slot if the export was cropped to the exact same ratio first. A 1200×300px export (4:1) squeezed into a 600×200px slot (3:1) distorts vertically the moment only one dimension is pinned. Always export at the same aspect ratio you'll display, then set both attributes.
Exporting at 2x only helps if the file survives compression looking sharp. Aggressive JPEG compression on a banner with text or logos introduces visible artifacts around hard edges — the opposite of what a Retina export is for. PNG avoids this for banners with flat color and type; JPEG is fine for photography-heavy banners as long as you check the compressed result at 100% zoom before uploading.
Honors CSS width/height reliably and doesn't care about export density on its own — but if the banner is base64-inlined, its encoded size counts toward the ~102KB total-HTML clip threshold. Hosted banners avoid that limit entirely.
Ignores CSS sizing on images; requires HTML width/height attributes as the override. No SVG support. Still the rendering path for Outlook 2016–2019 and classic Microsoft 365 desktop as of mid-2026.
Uses a browser-based engine and follows CSS sizing much more predictably. Inline SVG support is being retired here too, so PNG/JPEG banners are still the safe default.
width and height attributes set on the img tag, matching CSS valuesAround 600px or narrower for the display width, before accounting for Retina export. That keeps the banner inside the reading-pane width most Gmail and Outlook layouts use without forcing horizontal scroll, and it's the same figure MailSigCraft's own banner uploader suggests as a starting point.
2x is the right default for almost everyone — it covers the vast majority of Retina laptop and phone screens without ballooning file size unnecessarily. Reserve 3x for audiences you know are checking email primarily on the newest phones, since the extra pixel density adds real payload weight, especially if the banner is inlined as base64.
Almost always because the banner is embedded as a base64 data URI and its encoded size, combined with the rest of your signature's HTML, crossed Gmail's roughly 102KB clip threshold. Gmail truncates the message and shows a "[Message clipped] View entire message" link — anything below that point, including your disclaimer or social icons, goes with it. Switching to a hosted image URL removes the banner from that size calculation entirely.
Not directly — banner pixel dimensions and file size don't factor into spam scoring the way sender reputation or authentication does. But an oversized inline banner that triggers Gmail's clipping does hurt the reading experience, and a banner that fails to load or renders broken makes the whole email look untrustworthy, which indirectly affects whether people engage with it.
Yes, and animated GIFs are broadly supported, including in Outlook — but only the first frame renders in some older Outlook builds, so design the first frame to work as a complete, legible banner on its own rather than relying on the animation to convey the message.
Three numbers decide whether a signature banner survives the trip to an inbox: the display width you're designing for, the export density that keeps it sharp, and the payload size once it's inline or hosted. Pick 600px or narrower as your display width, export at 2x, set both width and height as HTML attributes for Outlook, and keep base64-inlined banners well clear of Gmail's clip threshold — or skip the math entirely by hosting the file instead.
Renders CSS-sized images correctly and displays high-density (@2x/@3x) exports at native sharpness on Retina and Super Retina displays automatically — no extra markup needed beyond correct width/height.