Gmail clips a message when the raw source is about 102KB. Readers see the top of the message, then "Message clipped" and a "View entire message" link, and most of them never click it. The cut often lands in the footer, right where your unsubscribe link and last CTA sit.
The size of your hosted images doesn't count towards that limit. The HTML, CSS, text, URLs, comments and tracking markup all do. Encoding and your ESP's link rewriting can also make the sent source bigger than the file on your disk, so leave yourself some headroom under 102KB.
What clipping costs you
If a table's left open at the cut, the layout can break. Open-tracking pixels at the bottom may never fire. And the unsubscribe link can vanish from the part people actually read, which nudges annoyed readers towards the spam button instead.
Some mobile Gmail apps clip earlier than desktop does. Treat 102KB as a ceiling, not a target, and aim for something closer to 80–90KB for the HTML you export.
How to measure the real size
Weigh the HTML you will send
Check the byte size of the compiled HTML after inlining, not the MJML source. MJML is short on purpose, and the inbox gets the compiled tables.
Account for the ESP
Lots of ESPs rewrite links, add tracking and change the encoding, so a 90KB file in your editor can tip over the line after import. Check the size again on a real Gmail send, or open "Show original" on a test and save that source.
Prefer "Show original" over the clipped view
The clipped web view isn't the size Gmail used to make its decision. "Show original" is much closer to the source that hit the limit.
Cuts that usually bring the file under the line
Remove unused CSS and comments. Inlining every style from a big stylesheet and then leaving the unused rules in the head is a classic way to blow past 102KB.
Shorten class names and repeated inline styles only where it's safe. A cleaner win is using fewer nested tables and fewer empty spacer cells.
Drop decorative markup. Extra wrapper tables, mobile blocks that duplicate the whole layout and long legal copy pasted in twice all add weight without making the offer any clearer. The same goes for Outlook-only scaffolding: keep only the Outlook email fallbacks you actually need.
Host your images. Don't Base64-embed them in the HTML: embedded images bloat the source fast and don't help with the clip the way people hope.
Stick to one column near 600px where you can. Separate desktop and mobile layouts double the markup, so go for a single structure that stacks, or MJML columns that compile once. See why MJML helps.
A lean export checklist
- Compiled HTML well under 102KB, ideally under about 90KB
- No Base64 images in the file
- No leftover CSS comments or unused rules
- Footer and unsubscribe still above the fold if the file were clipped mid-way
- A Gmail test send checked with "Show original" and with the clipped banner absent
For the rest of your pre-send checks, use the HTML email checklist.
Questions
Does Gmail clip based on image size?
No. Hosted image files don't count towards the clip limit, but the HTML and text markup do. Huge images still slow the email down when it opens, but that's a separate problem.
Why is my 90KB file still clipped?
Your ESP has probably made the source bigger with tracking links, template wrappers or encoding. Measure the sent source from "Show original", not just the file you exported. For the export and import itself, see how to export HTML or MJML for your ESP.
Should I put the tracking pixel at the top?
If opens matter and lots of your readers use a Gmail app with a lower clip threshold, a pixel near the top can still fire when the bottom is hidden. The layout and unsubscribe link still belong in a file that stays under the limit.