Updated · 8 min read
Why Gmail clips emails at 102KB (and how to stop it)
Gmail clips at 102KB. That number has been stable for thirteen years and most programs still hit it by accident, because the draft editor reports one size and the delivered email is another. What's actually going wrong is rarely the design — it's the wrappers, the comments, the inline CSS nobody audited, and a personalisation value that expanded by 40 characters on live send. Here's the mechanism, the six real sources of bloat, and the cap to enforce in QA.
By Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
What the 102KB limit actually means
102KB
Gmail's hard clipping threshold, stable since 2013.
~30%
Gmail's share of global email market. This is the binding constraint for most programs.
Low single%
Click-through on the 'View entire message' link after a clip.
The exact threshold is 102,400 bytes — 100 KiB, which Google rounds to 102KB in their own docs. Any HTML email above it gets truncated, and the tail is replaced with a "[Message clipped] 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/81126Thirteen years old. Still the same number. Applies in the Gmail web client and in the Gmail mobile apps on iOS and Android, and no other major client behaves this way — Apple Mail, Outlook, and Yahoo all render the full message regardless of size. Gmail is alone on this, which makes it the binding constraint for basically every consumer program.
Here's the part people miss: the limit is on the raw HTML source, not the rendered output. Everything counts. HTML tags, inline CSS, <style>blocks, hidden preheader text, tracking pixels, ESP-injected wrappers, HTML comments that were supposed to be stripped by the build. Externally-hosted images don't count — they're a URL reference, which is tiny — but inline data-URI images 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 tends to bite — 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.
The limit is on the raw HTML source, not the rendered output. That's why the email that looked fine in your editor gets clipped in the inbox.
Why you're probably closer to the limit than you think
Most ESPs bolt 8–20KB of wrapper markup onto whatever you built: link-tracking redirects, personalisation tokens that expand to their full values at send time, an unsubscribe footer block, DKIM and SPF metadata. If your raw template shows 85KB in the editor, your delivered email can easily cross 102KB on the wire — and the ESP preview won't show that wrapper expansion. That's the trap.
Where bytes go in a typical 95KB email A representative breakdown of a near-clipping email. Template markup is usually only a third of the actual byte count; the rest is ESP wrappers, inline CSS, comments, and unused style blocks — most of which can be eliminated without touching the design.
Check the final rendered size against a real send or a production-fidelity preview. Not the draft editor. Braze is a good 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 "Show original" to read the raw source. The Email Size Checker accepts the post-wrapper HTML directly, which saves the test-send step entirely.
The six things that actually bloat an email
1. Inline data-URI images.One 30KB logo encoded as base64 eats a third of the budget. Host images externally. 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 in and the builder inlined it.
2. Unused CSS. Template builders generate hundreds of class definitions you never actually use. Strip them. Purging unused CSS routinely reclaims 10–30KB of template output with no visual change at all.
3. HTML comments. Build-tool banners, Outlook conditional comments, 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. Often 5–15KB comes back immediately.
4. Duplicate inline styles. Every <td> carrying the same style block 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.
6. Embedded fonts. @font-facedeclarations carry real weight and rarely render consistently across clients anyway. Skip them. Use 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.
What 'safe' actually looks like
Under 60KB is comfortable. Between 60KB and 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, 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.
Frequently asked questions
- Why does Gmail clip long emails?
- Gmail's web and mobile clients truncate email HTML at 102 kilobytes. Anything beyond that gets hidden behind a "[Message clipped] View entire message" link. The threshold has been stable since 2014 and is enforced to reduce rendering cost and protect users from oversized payloads. Most clipped emails blow past 102KB not from content but from inlined CSS, nested table wrappers, and HTML comments left in by email builders.
- What is the Gmail 102KB clipping threshold?
- Gmail truncates the HTML body at exactly 102 kilobytes (unpacked, after MIME decoding). This is NOT the total email size including images — images are fetched separately. It's the HTML string size, which is driven by the template's markup, inline styles, and text content.
- How do I prevent Gmail from clipping my emails?
- Three practical steps. First, minimise inline CSS — use shared styles in a head block only for Gmail-safe properties, not a full reset. Second, strip HTML comments and empty table cells left by email builders. Third, move below-fold content to a linked landing page rather than embedding it. The Orbit Email Size Checker at /apps/email-size flags the size before send and identifies which sections are driving bytes.
- Does Gmail clipping affect tracking pixels and unsubscribe links?
- Yes — this is the worst downstream consequence. If the tracking pixel sits below the 102KB threshold, open-rate tracking breaks for Gmail users (exacerbated further by Apple MPP). If the unsubscribe link is below the threshold, users can't unsubscribe without clicking through to the full view first — a major CAN-SPAM and GDPR risk. Put the unsubscribe link above the fold and the tracking pixel near the top of the body.
- What's the difference between clipping and spam filtering?
- Clipping is a rendering decision — Gmail truncates the HTML but still delivers the message to the inbox. Spam filtering is a delivery decision — the message goes to Spam entirely. Clipping can contribute to spam signals indirectly (broken unsubscribe links, missing tracking pixels, weird rendering) but is not itself a spam-filtering mechanism.
This guide is backed by an Orbit skill
Related guides
Browse allTransactional emails: the highest-engagement messages you ignore
Order confirmations, password resets, receipts, shipping updates. Transactional emails post open rates two to three times higher than marketing sends — and most lifecycle teams have never touched them. Effort is going to the wrong place.
Email deliverability — the practitioner's guide
Deliverability isn't a setting. It's the running total of every send decision you've made since you bought the domain. Four pillars hold it up. Break one and the whole program starts leaking.
The unsubscribe page is the most important page in your lifecycle program
The page every lifecycle team ignores is the one quietly deciding sender reputation, suppression-list quality, and the fate of next quarter's deliverability. A short defence of why it deserves the ten-minute rebuild.
SPF, DKIM, and DMARC explained for lifecycle marketers
Three DNS records decide whether your marketing email is trusted or binned. Gmail and Yahoo made all three mandatory for bulk senders in 2024, and the grace period is over. This is the practitioner's explainer: what each one does, how they interact, and the setup order that won't block your own mail.
Dedicated vs shared IP: the real decision
Every ESP sales conversation pitches the dedicated IP as an upgrade. For most lifecycle programs it isn't — it's a trade, and often a losing one. Here's the volume threshold that actually justifies dedicated, the risks most teams don't anticipate, and when the shared pool is genuinely the better call.
List hygiene: the six-rule policy
List hygiene isn't cleanup; it's a continuous policy that runs automatically. Here's the six-rule policy every lifecycle program should have written down, each tied to a specific deliverability outcome.
Found this useful? Share it with your team.
Use this in Claude
Run this methodology inside your Claude sessions.
Orbit turns every guide on this site into an executable Claude skill — 54 lifecycle methodologies, 55 MCP tools, native Braze integration. Pay what it's worth.