Gmail clips your email at about 102 kB. Here is what it costs you.

Gmail stops rendering a message once it gets past roughly 102 kB and replaces the rest with a link that reads [Message clipped] View entire message. Google has never published the number in its own documentation, but every major email testing vendor reproduces the same threshold, and it has been stable for more than a decade.

That sounds cosmetic until you look at what normally sits at the bottom of a newsletter: the last products, the footer, the unsubscribe link and the tracking pixel. A clipped campaign hides part of your offer, quietly breaks your own reporting, and removes the visible way out of your list — which is the moment people reach for the spam button instead.

What actually counts towards the limit

The threshold applies to the message body as it is transmitted, not to what the reader sees. Two things follow from that, and both are counter-intuitive:

• Linked images do not count. A remote <img> is a URL of a hundred characters or so. The picture itself is fetched separately by the client and never enters the message size.
• Embedded images count enormously. Anything inlined as base64 lands inside the HTML, and base64 inflates the original file by about a third. One embedded logo can consume a quarter of your budget.
• Quoted-printable encoding counts too. Accented characters and long lines expand during transport, so the built file on your disk is smaller than the message Gmail measures.

So the thing that makes newsletters fat is almost never photography. It is markup.

Why the markup gets fat

• Inline styles. Email clients strip or ignore <style> blocks unevenly, so builders write every rule into every element. A single styled product card lands at roughly 1.5–2 kB before a word of copy.
• Nested tables. Layout in email is still tables inside tables, and each level repeats its attributes on every row and cell.
• Tracking parameters. Five UTM values on forty links is easily 4–6 kB of pure string.
• Duplicated blocks. A product grid pasted six times duplicates its markup six times. Builders rarely deduplicate anything.
• Merge tags that expand at send time. A coupon code, a recommendation block or a long first name adds bytes per recipient, after your preview looked fine.

What clipping costs in practice

Three effects show up, and they compound:

1. Clicks below the cut go to roughly zero. Not lower — essentially nothing, because the content is not on screen and the reader has no reason to expect more.
2. Your reporting lies. If the open pixel sits in the footer, clipped opens are not counted at all. Open rate drops, and you start optimising subject lines to fix a problem that is not there.
3. Complaints go up. When the unsubscribe link is behind “View entire message”, the spam button is the faster exit. Google's bulk sender guidelines put the enforced spam complaint threshold at 0.3 %, and recommend staying below 0.1 %. That is a very small budget to spend on a rendering bug.

How to stay under the line

1. Measure the built HTML, not the preview. Your builder should show the compiled size before you press send. If it does not, export the campaign and look at the file.
2. Cut products, not words. Four products with a reason to be there outperform twelve in a grid, and cost a fifth of the markup.
3. Shorten the tracking. One campaign parameter instead of five, and nothing at all on the unsubscribe link.
4. Put the unsubscribe link high. If it lives inside the first 60 kB, clipping stops being a compliance problem even when it happens.
5. Never embed images as base64. Host them and link them.
6. Send a real test to a real Gmail account and open it on a phone. Rendering previews do not reproduce clipping.

The rule worth adopting

Keep the built HTML under 80 kB. The 22 kB of headroom covers the personalisation that expands at send time, plus whatever a client's own wrapper adds in transit. It is a dull rule and it has no downside: there is no evidence anywhere that a heavier newsletter performs better than a lighter one.

If you only do one thing from this article, move the unsubscribe link above the product grid. It takes two minutes and it turns a rendering problem into a non-event.