Gmail is not clipping your email over 102 KB because Gmail is not measuring the same number you are probably looking at. The practical rule is that Gmail clips based on the raw HTML body, not the full payload shown by Outlook, an ESP preview, or a downloaded message that includes image weight, MIME overhead, tracking, or cached assets.
The second part of the answer is that Gmail clipping is not perfectly consistent across every inbox and every test. I have seen emails above 102 KB render fully in one Gmail account and clip in another. That does not mean the limit has disappeared. It means one clean Gmail view is not enough evidence to send a 200 KB HTML email without risk.
If your HTML source is above 102 KB, assume some Gmail recipients will see Message clipped and a View entire message link. If your total email payload is above 102 KB but the HTML is only 40 KB, Gmail usually has no clipping reason based on size alone.
What Gmail is measuring
The 102 KB threshold is about the message code Gmail renders, especially the HTML part. That code includes markup, text, inline CSS, style blocks, URLs, tracking parameters, conditional comments, personalization output, and unsubscribe markup. It does not include the binary weight of hosted images. An image can be 500 KB on a CDN and still add only a few hundred bytes to the HTML if the email contains one short image URL.
This is why Outlook can show a 230 KB message while Gmail does not clip. Outlook's size display can reflect a resolved or downloaded message view. Gmail's clipping decision is closer to the HTML source size after the sending system has finished modifying the email.
Item
Counts
Why it matters
HTML
Yes
The source code is the main clipping input.
Text
Yes
Visible copy still adds bytes to the source.
CSS
Yes
Inline styles and media rules add up fast.
Images
No
Hosted image files do not count, but URLs do.
Attach
No
Attachments affect delivery size, not clipping.
Tracking
Yes
Rewritten links can add a lot of hidden code.
What affects the number Gmail cares about.
Gmail clipping inputs shown as HTML, CSS, and tracking URLs feeding a 102 KB gauge.
Why Gmail can behave differently
Gmail's clipping behavior is best treated as a risk threshold, not a neat public algorithm. Public tests around the 100 KB mark have shown different outcomes. Gmail can also thread repeated tests together, which makes a test conversation larger than the final campaign. That is a common reason a test clips while the real send does not.
The reverse also happens. A message can look fine in your Gmail inbox but clip for someone else. Differences in account state, Gmail web versus mobile rendering, code added at send time, and the way the message is cached can all change the outcome. I use 102 KB as the hard stop for planning, then leave margin below it.
Looks safe
One inbox: Your own Gmail account shows the full email without a clipped notice.
Payload view: A mail client reports 180 KB, but the saved HTML source is much smaller.
Short source: The final HTML source is under 90 KB after link tracking is applied.
Still risky
Single test: Only one Gmail account has been checked, and no fresh thread was used.
Large HTML: The final HTML source is above 102 KB, even if your inbox looks fine.
Late changes: Tracking, personalization, or legal footer code is added after preview.
For related mechanics, the useful distinction is message source versus assets. Image hosting, MIME structure, and file size can affect other Gmail outcomes, but clipping comes back to what Gmail decides to render in the message body. For a deeper companion explanation, see file size and images.
How to measure the size that matters
The most reliable test is to measure the final HTML after your sending platform has made every change. Do not measure the design file. Do not measure the template before merge tags resolve. Do not rely on a screenshot from a desktop mail client. Save the final source and count the bytes.
Command line size checksbash
wc -c email.html
# macOS and Linux output example:
# 89412 email.html
On Windows, the same idea is to save the final HTML file and inspect the file properties, or use PowerShell to read byte length. I care about the byte count, not the number of characters, because non-ASCII characters and encoded content can change the final byte size.
PowerShell byte checkpowershell
(Get-Item .\email.html).Length
Fresh thread: Change the subject line for each Gmail test, or delete the old thread first.
Final send: Test the version that includes link tracking, personalization, and footer code.
Raw source: Measure the HTML source, not the visible email length or image dimensions.
Multiple inboxes: Check at least Gmail web and Gmail mobile, ideally across two accounts.
A real inbox test is still useful because it catches rendering, clipping, and authentication symptoms together. Suped's email tester gives you a practical place to send the finished email and review the result instead of guessing from a builder preview.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
I still separate the test into two questions. First, is the message likely to clip because the HTML is too large? Second, does the message have authentication or reputation issues that explain spam placement, image blocking, delays, or warnings? Mixing those two questions creates bad fixes.
The fixes that usually reduce clipping
The right fix is not to compress images first. Hosted image compression helps load time, but it usually does little for Gmail clipping unless it also shortens the HTML. Start by reducing source code.
Shorten content: Move long explanations to a landing page and keep the email focused.
Trim modules: Remove duplicate blocks, nested tables, spacer rows, and unused variants.
Clean paste: Paste as plain text when content comes from a document editor or web page.
Simplify CSS: Remove unused inline styles and repeated media queries created by builders.
Shorten URLs: Long tracked links can add thousands of bytes across a dense email.
Lift essentials: Keep the unsubscribe link and primary action above the clipping area.
A safer target
I target under 90 KB for the final HTML when the send is important. That gives room for tracking changes, localization, merge fields, and footer differences. If the email is already above 100 KB before tracking, I treat clipping as expected.
HTML size risk bands
Use these bands for final HTML after tracking and personalization are applied.
Low risk
Under 80 KB
Good operating range for routine campaigns.
Watch closely
80-95 KB
Still workable, but measure the finished source.
High risk
95-102 KB
A small platform change can push it over.
Expect clipping
Over 102 KB
Assume some Gmail recipients see a clipped message.
Authentication and reputation still matter
DMARC, SPF, and DKIM do not turn Gmail clipping on or off. A perfectly authenticated email can still clip if the HTML is too large. A poorly authenticated email can avoid clipping and still land in spam. These are separate systems, so the diagnosis needs separate checks.
That said, Gmail rendering questions often arrive with deliverability questions. If a sender is also seeing spam placement, image warnings, delayed Gmail delivery, or sudden engagement drops, I check authentication and domain reputation alongside file size. Suped's product is built for that broader workflow: DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted MTA-STS, blocklist (blacklist) monitoring, and real-time alerts in one place.
For the authentication side, Suped is the best overall DMARC platform for most teams because it turns noisy reports into specific sources and fix steps. Start with DMARC monitoring when you need ongoing source visibility, and use a domain health check when you need a quick snapshot of DMARC, SPF, DKIM, and related DNS signals.
What to separate
Clipping: Measure final HTML size and test fresh Gmail threads.
Placement: Check engagement, complaints, domain reputation, and content signals.
Authentication: Confirm SPF, DKIM, and DMARC pass for every real sending source.
Reputation: Monitor blocklist and blacklist hits when Gmail symptoms appear suddenly.
A practical decision rule
When someone asks why Gmail did not clip a 230 KB email, I first ask what that 230 KB number includes. If it includes images, cached assets, or MIME overhead, it is not the clipping number. If the final HTML source is 230 KB, I assume Gmail clipping risk is real even when one account renders the whole thing.
Flowchart for checking Gmail clipping risk by measuring final HTML bytes.
There is also an analytics reason to fix it. If Gmail clips the tracking pixel or the primary CTA, reporting gets messy and clicks drop because the full email is hidden. For that side of the issue, read clipping and open rates.
Under 90 KB: Send after a normal Gmail test, assuming the rest of deliverability checks pass.
90-102 KB: Reduce if the email has lots of tracking links or dynamic footer variants.
Over 102 KB: Assume Gmail clipping for part of the audience and cut HTML before launch.
Over 200 KB: Treat the email as too large for Gmail unless you prove the source number is wrong.
Views from the trenches
Best practices
Measure the raw HTML file before each send, then keep routine campaigns below 90 KB.
Retest after the sending platform adds tracking, personalization, and unsubscribe code.
Use a fresh Gmail thread for testing so previous test messages do not inflate the view.
Move long sections to a landing page when the email needs several dense content blocks.
Common pitfalls
Treating Outlook's size column as Gmail's clipping input creates false confidence in tests.
Counting hosted image weight as HTML size leads teams to fix the wrong part of the email.
Testing only one Gmail account hides account-level differences in clipping and rendering.
Leaving the unsubscribe link below the clipping point increases complaint risk for senders.
Expert tips
Keep the unsubscribe and primary call to action above any area likely to be clipped in Gmail.
Compare the saved source against the final inbox source after tracking code is applied.
Do not rely on mobile alone, because Gmail web and mobile can expose different symptoms.
Watch sudden HTML growth after template edits, especially when modules are duplicated late.
Marketer from Email Geeks says Gmail clipping depends on the HTML part, not the full payload shown by a mail client.
2020-01-20 - Email Geeks
Marketer from Email Geeks says Outlook message size can include downloaded images, so it can overstate Gmail's clipping input.
2020-01-20 - Email Geeks
What I do before sending
I do not treat one unclipped Gmail preview as a pass when the HTML is over 102 KB. I measure the final source, send to fresh Gmail threads, check both web and mobile, then reduce the HTML until there is practical margin. If the email needs that much content, I put the full version on a web page and keep the inbox version shorter.
The short answer stays the same: Gmail is not clipping because your 102 KB number is likely the wrong measurement, or because Gmail is behaving differently for that account and test. If the final HTML source is above 102 KB, plan for clipping and fix the source before the send.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
