· 8 min read
Why Gmail clips emails at 102KB (and how to stop it)
The Gmail 102KB clipping limit has been killing lifecycle campaigns since 2013. CTAs, unsubscribe links, legal footers — all at risk of landing below the fold when Gmail decides your email is too big. What makes this insidious is how often the clipping happens to emails that looked fine in the draft editor. Here's why the limit exists, what actually counts against it, and the disciplined way to keep every send in the safe zone.
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.
Gmail truncates any HTML email larger than 102,400 bytes (100 KiB, which Google rounds to 102KB in their own documentation) and replaces the cut-off portion 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/81126The threshold has been stable for over a decade. It applies in the Gmail web client and Gmail mobile apps on both iOS and Android.
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, and HTML comments. Externally-hosted images don't count — they're referenced by URL — but inline data-URI images absolutely do, and they can eat through the budget fast.
Once Gmail clips an email, the click rate on the "View entire message" link is consistently in the low single digits. Everything past the clip point is effectively invisible: your secondary CTAs, your unsubscribe link, your legal footer. That last point matters — in some jurisdictions, rendering the unsubscribe inaccessible to most recipients can create compliance risk, and a clipped unsubscribe usually drives complaint rate up (the unsubscribe page guide covers why that shift matters more than people think).
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
A typical ESP adds 8–20KB of wrapper markup on top of whatever you built: link-tracking redirects, personalisation tokens expanded to their full values at send time, an unsubscribe footer block, and DKIM/SPF metadata. If your raw template is at 85KB in the editor, your delivered email can easily cross 102KB — and the ESP preview won't show that wrapper expansion.
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.
The implication: always check the final rendered size against a real send or a production-fidelity preview, not the draft editor's reported size. The Email Size Checker accepts the post-wrapper HTML directly so you can see the number that actually reaches Gmail.
The six things that actually bloat an email
1. Inline data-URI images. A single 30KB logo encoded as base64 will eat a third of your budget. Always host images externally and reference them by URL. No exceptions — this is the single most common cause of unexpected clipping.
2. Unused CSS. Template builders generate hundreds of class definitions you never actually use. Strip them before send. Purging unused CSS often cuts 10–30KB from template output.
3. HTML comments. Build-tool banners, Outlook conditional comments, developer notes, commented-out sections — they all ship to the inbox. Run a comment stripper as part of your build. This single step often reclaims 5–15KB.
4. Duplicate inline styles. Every <td> with the same style block repeats every byte. Consider consolidating into a scoped <style> block with Outlook-safe selectors.
5. Overly precise pixel values. CSS generators often output values like margin-top: 12.7389px. Round them. You won't see the visual difference, and the bytes add up.
6. Embedded fonts. @font-face declarations and the fonts they reference can add significant weight and rarely render consistently across email clients anyway. Skip them; use web-safe fallbacks.
Most templates drop 20–40% of their weight from these six changes alone, with no visible impact on the recipient.
What 'safe' actually looks like
Under 60KB is a comfortable headroom for most templates. Between 60KB and 80KB is fine but watch the trend. Over 80KB starts to feel precarious. Over 95KB you're gambling — one typo in a personalisation token that expands to a longer value than expected can push you over the threshold on a specific send.
Discipline that works in practice: enforce a soft cap at 80KB in QA. Anything above requires explicit review and a documented reason. The Email Size Checker enforces this with warnings at 80% of the limit and errors at the clip threshold so you see the problem before you hit send. The Orbit Email Render QA skill wraps the full pre-send checklist — size, Liquid fallbacks, dark-mode safety, link integrity — into a single automated gate.
The most expensive version of this failure pattern: a campaign that was 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, or a localised string in a language with longer words). Inspect the actual personalisation data ranges, not just the template.
Frequently asked questions
- Does Gmail clip emails at exactly 102KB?
- The threshold is 102,400 bytes (100 KiB). Google rounds it to 102KB in their own documentation. Emails above that size are truncated in the Gmail web client and mobile apps. The limit has been stable since 2013 and is confirmed in Gmail's sender guidelines.
- Do other email clients have the same clipping issue?
- No — Gmail is unique in imposing this client-side limit. Apple Mail, Outlook, and Yahoo Mail render the full message regardless of size. However, Gmail represents roughly 30% of global market share (much higher among consumer audiences) so it's the binding constraint for most programs.
- Do images count toward the 102KB limit?
- Externally-hosted images don't count — only their <img> markup does, which is tiny. Inline data-URI images (data:image/png;base64,...) absolutely count and are one of the biggest causes of unexpected clipping. Always host images on a CDN and reference them by URL.
- Does the 102KB include the tracking pixel and footer my ESP adds?
- Yes. Link-tracking redirects, personalisation tokens that expand to longer values, ESP unsubscribe footers, and DKIM-related headers all count toward the delivered size. Budget your template around 80KB to allow 20KB of wrapper expansion at send time.
- What happens to links and the unsubscribe footer if my email is clipped?
- They disappear from the visible rendering. The recipient sees a 'View entire message' link instead. Click-through on clipped emails is measurably lower, and — more importantly — your legally-required unsubscribe link may become invisible, which creates compliance risk in jurisdictions with strict unsubscribe requirements.
- How do I reduce email size without redesigning the template?
- Four cheap wins in order: strip HTML comments (often 5–15KB), remove unused CSS classes from your builder's output (often 10–30KB), replace inline data-URI images with hosted URLs, and collapse duplicated inline styles into a single <style> block. Most templates drop 20–40% of their weight from these four changes alone.
- Can I preview the final delivered size in Braze?
- Braze shows the raw template size in the campaign editor, but the delivered size includes tracking link rewrites and the Braze wrapper — neither visible in the preview. Send a test to a Gmail address and check the raw source via 'Show original' to see the true delivered size, or paste your HTML into the Orbit Email Size Checker for the same answer without sending a test.