Why Gmail clips emails at 102KB (and how to stop it)

Picture the moment a campaign goes out and someone forwards you the Gmail copy. The hero looks fine. The body reads cleanly. Then, where the unsubscribe link should sit, there's a small grey line: [Message clipped] View entire message. Everything past that point — secondary CTA, footer, legal copy, the unsubscribe link your compliance team insisted on — is hidden behind a click almost nobody makes. That's the failure mode this guide is about, and it has one trigger: your HTML crossed 102 kilobytes.

The exact threshold is 102,400 bytes — 100 KiB, which Google rounds to 102KB in its own docs. Any HTML email above it gets truncated, with the tail replaced by that "View entire message" link.Source · GoogleGmail sender guidelinesOfficial Google documentation covering email size, clipping behaviour, and sender requirements for reliable Gmail delivery.support.google.com/a/answer/8112613 years old. Still the same number. Applies in the Gmail web client and the Gmail mobile apps on iOS and Android. No other major client behaves this way — Apple Mail, Outlook, and Yahoo render the full message regardless of size. Gmail is alone on this, which makes it the binding constraint for basically every consumer program.

The bit most teams miss: the limit is on the raw HTML source — the markup the browser parses, before it's rendered into anything you see — not the visual output. Everything in that source counts. HTML tags, inline CSS (style declarations written directly on each element), <style>blocks, hidden preheader text, tracking pixels, the wrapper markup your ESP — your email service provider, the platform that actually sends the message — injects on the way out, even HTML comments your build was supposed to strip. Externally hosted images don't count, because they're a URL reference and a URL is tiny. Inline data-URI images — pictures encoded directly into the HTML as base64 text — absolutely do, and one base64 logo can wipe out a third of the budget without warning.

Clipped emails see click-through on the "View entire message" link consistently in the low single digits. Everything past the clip is effectively invisible: secondary CTAs, unsubscribe, legal footer. That last point is the one that bites. In several jurisdictions burying the unsubscribe link creates real compliance risk, and a clipped unsubscribe reliably drives the complaint rate up. The unsubscribe page guide has the full shape of that risk.

Most ESPs bolt 8–20KB of wrapper markup onto whatever you built before the message leaves their system: link-tracking redirects (so they can attribute clicks), personalisation tokens that expand to their full values at send time (a 12-character placeholder becomes a 47-character first name plus product), an unsubscribe footer block, DKIM and SPF metadata for authentication. If your raw template shows 85KB in the editor, the delivered email can easily cross 102KB on the wire — and the ESP preview almost never shows that wrapper expansion. That's the trap. The version you QA'd isn't the version the recipient receives.

Check the final rendered size against a real send or a production-fidelity preview. Not the draft editor. Braze is a clean example of the trap in practice: the campaign editor shows raw template size, but the delivered payload includes tracking link rewrites and the Braze wrapper, neither of which the preview reports. Send a test to a Gmail address and use Gmail's "Show original" option (in the three-dot menu on any open message) to read the raw source as the inbox actually received it. The Email Size Checker accepts the post-wrapper HTML directly, which saves the test-send step entirely.

Six culprits account for almost every accidental clip. The design is rarely one of them, and an afternoon of audit work is usually enough to clear the lot.

1. Inline data-URI images.One 30KB logo encoded as base64 — the format that turns binary image data into a long string of text characters, so the image lives inside the HTML instead of at a separate URL — eats a third of the budget. Host images externally on a CDN. Reference them by URL. No exceptions. This is the single most common cause of unexpected clipping and it's almost always accidental: someone pasted a logo into the editor and the builder silently inlined it.

2. Unused CSS. Template builders generate hundreds of class definitions you never actually use. Purge them as a build step — it routinely reclaims 10–30KB of template output with no visual change at all.

3. HTML comments. Build-tool banners, Outlook conditional comments (the special <!--[if mso]> blocks that target old Outlook versions), developer notes, commented-out sections from three campaigns ago — every one of them ships to the inbox. Run a comment stripper as part of your build. 5–15KB usually comes back immediately.

4. Duplicate inline styles. Every <td> table cell carrying the same style declaration repeats every byte. Consolidate into a scoped <style> block with Outlook-safe selectors where you can.

5. Overly precise pixel values. CSS generators output things like margin-top: 12.7389px. Round them. The recipient cannot tell the difference between 12.7389 and 13 on a phone screen, and the bytes compound across a whole template.

6. Embedded fonts. @font-facedeclarations — the CSS that tells the client "use this custom font" — carry real weight and rarely render consistently across email clients anyway. Drop them in favour of web-safe fallbacks. The visual gain isn't worth the byte cost, full stop.

Most templates drop 20–40% of their weight from those six changes alone, with no visible impact on the recipient. If you've never audited, that's where the first pass goes.

Under 60KB is comfortable. 60KB to 80KB is fine but watch the trend. Over 80KB starts to feel precarious. Over 95KB you're gambling — one personalisation token that expands to a longer value than you planned can push you past the threshold on a specific send, and you won't know until the complaints land.

The discipline that actually works: enforce the 80KB soft cap in QA, no exceptions without a documented reason. The Email Size Checker warns at 80% of the limit and errors at the clip threshold, so the problem surfaces before send. The Orbit Email Render QA skill folds the full pre-send checklist — size, Liquid fallbacks (the templating language ESPs use to inject personalised values, and the safety net for when those values are missing), dark-mode safety, link integrity — into one automated gate.

The failure mode nobody budgets for: a campaign safely under 80KB in test grows past 102KB on live send because of a longer-than-expected personalisation value. A user with a 40-character product name. A localised string in German where English was 15 characters. Inspect the data ranges, not just the template. This is the version of the problem that lands on Friday afternoons and ruins weekends.

One thing to do Monday: set the 80KB soft cap as a hard gate in your QA flow. Every other fix in this guide compounds behind that single rule.