Email Weight Checker
When an HTML email exceeds 102 KB (102,400 bytes), Gmail abruptly cuts the message short with a [Message clipped] View entire message prompt. This breaks campaign analytics by discarding open tracking pixels, hides your legal footer and unsubscribe link (driving up spam complaints), and cuts off your calls to action. This free tool tests your email HTML weight in real time, accounts for Email Service Provider (ESP) wrapper overhead, visualizes the exact cutoff point, and calculates code savings from minification. Everything runs locally in your browser — your email code is never uploaded or saved.
Free deliverability tool · 100% in-browser
Check your email weight & Gmail clipping risk
Test your HTML email against Gmail's 102 KB threshold, simulate ESP tracking injection, pinpoint cutoff locations, and optimize code before sending.
- Gmail 102 KB threshold
- ESP overhead buffer
- Code weight breakdown
- Unsubscribe audit
1Your email HTML code
.html or .eml file here, or
ESPs wrap links for click tracking, inject open tracking pixels, and expand merge tags, adding invisible weight to your email in the inbox.
2Gmail clipping verdict
Paste HTML or click Load sample to calculate size and Gmail clipping risk.
Calculating weight...
- Raw HTML 0 B 0.0 KB
- Projected In-Inbox 0 B Raw + ESP
- Buffer Headroom 0 B To 102.4 KB
- Minify Savings 0 B 0% recoverable
3Component weight breakdown
See where your bytes are going. Identifying whether inline styling, bloated comments, or embedded media dominate your file tells you exactly what to clean first.
4Deliverability & clipping audit
-
Info
Awaiting template code Enter your HTML email or load a sample above to audit Gmail clipping, unsubscribe link accessibility, and open tracking safety.
5Clipping boundary inspector
No email code loaded. Once you provide HTML, this panel will identify whether your code crosses byte 102,400 and reveal the exact markup where Gmail cuts off.
What is the Gmail 102 KB clipping threshold?
The Gmail clipping threshold is a strict rendering limit enforced across all Google Gmail clients — including the desktop web app, Android app, iOS app, and mobile web. When an incoming email message has an HTML payload that exceeds 102 KB (exactly 102,400 bytes or 100 KiB), Gmail ceases rendering the message markup at that exact byte boundary. In place of the remaining email, Gmail appends a small text prompt:
[Message clipped] View entire message
To view the rest of your email, the recipient is forced to click that link, which opens the full email in a separate browser tab. Because fewer than 5% of readers ever click through to view the clipped portion, exceeding 102 KB effectively erases the bottom half of your campaign.
Crucially, this limit measures the raw UTF-8 byte size of the HTML file itself — not the weight of external images. If your email contains ten high-resolution photographs hosted on an external content delivery network (CDN) totaling 5 megabytes, those images do not count toward the 102 KB threshold. However, every character of your HTML markup, inline CSS styles, link URLs, tracking parameters, HTML comments, and base64 embedded data counts directly against this 102,400-byte budget.
Why email clipping is catastrophic for email deliverability and ROI
Many email designers view clipping as a minor visual inconvenience. In reality, Gmail message clipping is one of the most severe technical hazards in email marketing, triggering cascading failures across analytics, compliance, and sender reputation:
1. Open tracking pixels are completely silenced
Every major Email Service Provider (ESP) — including Klaviyo, Mailchimp, HubSpot, ActiveCampaign, Brevo, and Salesforce Marketing Cloud — tracks email opens by injecting an invisible, single-pixel image (<img src="...open-tracker.gif">) at the very bottom of the HTML template, immediately before the closing </body> tag. When Gmail clips an email at byte 102,400, that tracking pixel is cut from the DOM. Unless the recipient manually clicks "View entire message", the tracking pixel never loads, and the ESP records the recipient as never having opened the message. Senders who cross the 102 KB threshold routinely observe an artificial 20% to 50% drop in reported open rates.
2. The unsubscribe link disappears, causing spikes in spam complaints
In accordance with industry layout conventions and design best practices, the unsubscribe link and preference center controls are placed in the footer at the bottom of the email. When an email is clipped, the unsubscribe link is hidden behind the fold. When subscribers wish to opt out but cannot find an unsubscribe link, their immediate recourse is to click Gmail's prominent "Report Spam" button. A surge in spam complaints directly degrades your domain and IP sending reputation, causing future broadcasts to land in the Junk folder across all mailbox providers.
3. CAN-SPAM, CASL, and GDPR legal non-compliance
Global privacy regulations mandate that commercial emails contain a clear opt-out mechanism and the sender's valid physical postal address. If your footer is clipped, your broadcast fails these legal requirements for millions of Gmail recipients. Under strict corporate governance, sending clipped emails exposes businesses to legal liability and platform suspension by ESP compliance teams.
4. Critical calls to action and discount codes are cut off
In retail and B2B emails, the bottom half of the email frequently contains secondary product recommendations, customer testimonials, return policy details, warranty guarantees, and post-script (P.S.) conversion links. Clipping leaves readers with a truncated, half-rendered visual experience that damages brand credibility.
The hidden ESP overhead factor: Why raw code is not enough
One of the most frequent traps email developers encounter is measuring their template file on their local hard drive, seeing an 88 KB file, and assuming the email is safe from clipping. Then, after sending a live campaign through Klaviyo or Mailchimp, they discover Gmail clipped the message anyway.
This discrepancy occurs because ESPs automatically inject substantial wrapper markup during message compilation. When your broadcast is dispatched, your ESP transforms your raw HTML:
- Click tracking redirect wrapping: Every hyperlink in your message (
<a href="https://example.com/product">) is rewritten into an ESP tracking URL (such ashttps://trk.mail.yourbrand.com/wf/click?upn=K9aB8xQ2...), adding 80 to 140 bytes of URL bloat per link. An email with 30 links gains 3 KB to 4 KB of weight from link tracking alone. - ESP wrapper divs and container tables: ESPs inject outer wrapper tables, preheader spacing tags, dynamic conditional containers, and metadata attributes for web-version archives.
- Personalization tag expansion: Liquid and merge tags like
{{first_name}}or{{billing_address}}are short in your draft, but expand to full recipient strings upon delivery. - Compliance footers: If your ESP automatically appends mandatory system footers or unsubscribe tokens, this injects an additional 2 KB to 5 KB of HTML.
Because ESP compilation typically adds between 5 KB and 15 KB of invisible HTML weight, your safe design limit is not 102.4 KB. You should maintain a strict ceiling of 85 KB (87,040 bytes) on your raw source code, leaving an intentional buffer for ESP injection.
Email client clipping and size behavior comparison
While Gmail is the most famous for enforcing a hard byte limit, other email clients handle heavy payloads with varying behaviors. The table below outlines how major inbox providers process email weight:
| Email Client / Provider | Clipping Threshold | Truncation Behavior | Open Tracking Impact | Mobile App Consistency |
|---|---|---|---|---|
| Google Gmail (Web) | 102 KB (102,400 bytes) | Hard cut with [Message clipped] link |
Tracking pixel truncated; opens lost | Enforced identically across desktop browsers |
| Gmail App (iOS & Android) | 102 KB (102,400 bytes) | Hard cut with tap-to-expand prompt | Tracking pixel truncated; opens lost | Identical 102 KB rule enforced |
| Yahoo Mail | ~100 KB – 150 KB | Occasional clipping depending on account tier | Tracking pixel usually executes | Mobile app occasionally truncates rich layouts |
| Outlook (Desktop & 365) | No byte clipping limit | Renders full document | Tracking pixel fires normally | Word rendering engine has layout bugs, but no byte cut |
| Apple Mail (iOS & macOS) | No byte clipping limit | Renders full document | Mail Privacy Protection (MPP) pre-caches tracking pixel | Full render; responsive CSS supported |
5 Practical techniques to slim down bloated email code
If your email exceeds the 85 KB safe threshold or crosses the 102.4 KB limit, use these proven optimization techniques to trim 20 KB to 50 KB of dead weight without sacrificing design quality:
1. Eliminate inline Base64 data URIs immediately
The single most destructive cause of accidental Gmail clipping is embedding images as base64 strings (e.g., <img src="data:image/png;base64,iVBORw...">). A 30 KB PNG graphic expands by approximately 33% when encoded as base64 text, injecting 40,000 characters of raw code directly into your HTML payload. Always upload images to your ESP's media library or a dedicated CDN, referencing them with standard HTTP/HTTPS URLs.
2. Strip framework comments and debug markup
Modern email frameworks like MJML, Foundation for Emails, and drag-and-drop template builders generate extensive developer annotations and commented Microsoft Outlook conditional tables. While MSO conditionals (<!--[if mso]>) are necessary for rendering in legacy desktop Outlook, non-conditional developer comments (<!-- BEGIN HERO SECTION -->) should be removed prior to broadcast. Stripping comments frequently saves 4 KB to 12 KB.
3. Minify HTML and collapse redundant whitespace
Indented code with four spaces per line and double carriage returns makes templates legible for developers, but wastes precious bytes. HTML minification collapses whitespace between closing and opening tags (e.g., > < becomes ><). This simple step typically shrinks file size by 10% to 18% without affecting visual layout.
4. Consolidate repetitive inline CSS
Because Gmail previously had spotty support for embedded <style> tags, email developers historically inlined every CSS rule onto every single element. However, repeating style="font-family:Arial,sans-serif;font-size:14px;color:#333333;line-height:1.5;" across 40 table cells generates massive code bloat. Since 2016, modern Gmail supports <style> blocks inside the document <head>. Move global typography, link colors, and button styles into class selectors, and only inline element-specific positioning.
5. Prune excessive product listings in digests
If your newsletter showcases 25 separate product blocks with individual buttons, images, and description paragraphs, the sheer volume of HTML table structures will push the document past 100 KB. Curate your newsletters to highlight your top 6 to 8 items, and direct subscribers to a dedicated category page on your website for the remainder.
Frequently asked questions about email weight and clipping
Does Gmail count image file sizes or just HTML code?
Gmail counts only the HTML code toward the 102 KB clipping threshold. If you have five images that are 500 KB each hosted on a web server, their image file sizes do not count toward the 102 KB limit. The only part that counts is the URL string in the HTML (e.g., <img src="https://cdn.example.com/photo.jpg">, which is approximately 50 bytes). The only exception is base64 images, which are encoded as text inside the HTML document itself.
Why did my email clip when my code editor said it was only 92 KB?
Code editors measure the file size of your raw template. When you upload that template to an ESP like Klaviyo, Mailchimp, or Salesforce Marketing Cloud, the platform wraps every link with tracking redirects, injects open-tracking pixels, and adds legal footers. This overhead regularly adds 8 KB to 15 KB of code, pushing a 92 KB draft past Gmail's 102.4 KB ceiling.
Can I test Gmail clipping by sending a test email to myself?
Yes, but with one critical caution: if you send multiple test emails with the same subject line to the same Gmail address, Gmail will thread them into a conversation. Gmail clips threaded conversations when the combined conversation weight exceeds 102 KB. To accurately test a single email, change the subject line on every test or delete prior test threads from your inbox before sending.
Will minifying my email HTML break rendering in Outlook?
Safe minification — which preserves MSO conditional comments (<!--[if mso]>...<![endif]-->) — will not break Outlook. However, avoid aggressive JavaScript minifiers that strip comment syntax completely, as Outlook relies on conditional comments to render table widths correctly.
What should I do if my campaign already went out clipped?
If a broadcast has already been sent, you cannot unclip messages in recipients' inboxes. However, you should immediately check your ESP's real-time reporting. If open rates appear lower than normal, explain the technical discrepancy to stakeholders: opens were undercounted because the tracking pixel was clipped. For future broadcasts, use this checker to ensure your template stays under 85 KB before hitting send.
Related deliverability and marketing tools
- Subject + Preheader Tester (#53) — Preview how your subject line and preheader text render in mobile and desktop inboxes before broadcast.
- Email Accessibility Checker (#56) — Audit HTML email contrast, alt text attributes, and screen-reader hierarchy.
- Unsubscribe Compliance Checker (#60) — Verify one-click unsubscribe headers, CAN-SPAM footers, and GDPR compliance.
- Cold Email Subject Line Grader (#26) — Grade subject line length, spam triggers, and personalization strength.
- Email Marketing & Deliverability Consulting — Professional technical audit for sender reputation, inbox placement, and custom HTML design.
