Gmail clipping: why long HTML emails get cut off, and the fix
Gmail cuts off HTML messages above roughly 102 KB and hides the rest behind a link. Learn what counts toward the limit, how to measure it and how to stay under.

On this page(10 sections)
You send an order summary, a long digest or a receipt with many line items. In your own preview it looks perfect. In Gmail, the bottom of the message is missing, and a small grey link reads "Message clipped. View entire message". The customer never sees the footer, the second half of the table, or the button you put at the end.
This is Gmail clipping, and it is one of the most common ways a correct template ends up looking broken. It is also easy to prevent once you know what is counted and what is not.
What clipping is
Gmail shows a limited amount of an HTML email in the inbox view. When the HTML source of a message goes past a size threshold, commonly cited as about 102 KB, Gmail cuts the message there and adds a link to view the whole thing in a separate page. The exact number is not a published promise and can change, so treat 102 KB as a ceiling you should stay well below, not a target.
Three details matter:
- It counts the HTML source, not what the reader sees. A message that looks short can have a huge source because of repeated styles, nested tables and long URLs.
- Images do not count when they are linked. An image hosted on a server adds only its tag. An image embedded directly in the HTML (for example as base64 data) adds its full size to the source, and can push you past the limit alone.
- Plain text and attachments are separate. The limit is about the HTML part of the message.
Why it hurts more than it looks
The part that gets cut is the end of the document. That is where many templates keep important things:
- The footer, with the sender's address, support contact and legal text.
- The unsubscribe link in the body. A one-click unsubscribe header still works, as covered in one-click unsubscribe, but readers who look for a link in the message will not find it.
- Calls to action placed at the bottom, such as "Pay now" or "Review your order".
- Tracking pixels, which usually sit at the end. If the pixel is cut off, the open is never recorded, so your open numbers drop for no reason you can see.
Clipping is also invisible to the sender. You do not get an error, a bounce or a warning. The message is delivered and the metrics simply look odd.
How to measure your messages
Do this on a real, fully rendered message, not on the template file. Merge fields, loops and personalization can multiply the size.
- Render the final HTML with a realistic worst-case data set: the customer with 40 line items, the longest name and the most notes.
- Check the byte size of the HTML body. On the command line,
wc -c message.htmlgives bytes. Divide by 1,024 for kilobytes. - Send it to a Gmail test address and open it in the web client and the mobile app. Scroll to the bottom and look for the clipped link.
- Add a check to your pipeline so a template that grows past a limit you choose, for example 80 KB, fails the build. Email tests in CI shows how to wire a rendering test into your normal checks, and a preview and test-send feature helps with the manual side.
Choose an internal budget below the real limit. Gmail may count slightly differently than your tool does, for instance with character encoding, so leave a margin of 15 to 20 percent.
What makes HTML heavy
Most oversized emails come from a short list of causes.
Repeated inline styles. Email needs inline CSS for compatibility, and every element carries its own style="...". A long table with the same ten style declarations on each of 100 cells is mostly repetition.
Deeply nested tables. Layout tables inside layout tables inside layout tables add tags, attributes and whitespace to every level.
Generated markup from visual editors and frameworks. Some tools output comments, conditional blocks for old Outlook versions, and long attributes that you do not need.
Embedded images. A base64 logo can add tens of kilobytes. A few of them can fill the budget alone.
Long tracking URLs. Each link rewritten with a long tracking token can add 200 to 500 characters. A message with fifty links adds up quickly.
Hidden text. A long preheader padded with invisible characters, or duplicate text for screen readers or alternate layouts, is still counted.
Whitespace and comments. Pretty-printed templates carry indentation and comments that mean nothing to the reader.
How to bring it down
Start with the biggest wins and re-measure after each one.
- Host images, link to them. Replace any embedded image data with a normal image URL. Transactional HTML rendering constraints explains how clients treat remote images and what to do for readers who block them.
- Minify the HTML. Remove comments, extra whitespace and line breaks. Keep conditional comments you really need for Outlook, but not the ones left by an old template.
- Shorten your styles. Use a build step that inlines CSS from a stylesheet, then remove unused rules. Prefer a few shared properties over long lists on every cell. Where clients support it, a
<style>block in the head for media queries and shared rules is smaller than repeating them. - Flatten the layout. Remove wrapper tables that do not change the layout. A single column is often one table, not five.
- Shorten link URLs. If you use link tracking, use a short tracking domain and short tokens. See custom tracking domains for how it fits into sender reputation.
- Cut or paginate long content. A digest of 100 items does not need to be in one message. Show the top ten and link to the full list on the web. The reader will usually prefer it.
- Put what must be seen near the top. Place the key information and the main button early, and make sure the footer does not carry anything critical.
- Move the tracking pixel earlier, if you use one, or accept that it is unreliable for long messages. Open tracking is already an imperfect measure.
- Link to a web version for very long messages and make that link visible near the top.
A note on dynamic content
Messages built from a loop, such as receipts and activity summaries, are the ones most likely to be clipped, because their size depends on the customer. Put a cap in the template code: show the first 20 line items, then a line such as "and 15 more items" with a link. Test with your largest customer, not your average one.
Gmail and the plain-text part
Because the limit applies to the HTML part, the plain-text part is not clipped in the same way. Writing a proper text version helps readers who use text view and clients that prefer it. See why the plain-text part matters. It is no substitute for fixing the HTML, but it is a useful fallback.
Does it change by device?
Clipping shows up in the Gmail web client and the mobile apps, and the same message may be clipped in one and not another if the client counts differently. Other clients have their own limits and quirks. Do not assume that passing in Gmail means passing everywhere, and do not assume that an old fix still holds: re-check after any big template change.
A short checklist
- Final rendered HTML for the largest realistic case is under your budget (for example 80 KB)
- No images embedded as data; all images hosted
- HTML minified and CSS inlined without waste
- Deep nesting flattened where possible
- Long lists capped with a link to the full view
- Key content and main button near the top
- A size check runs in your build or test pipeline
- Opened in Gmail web and the mobile app, bottom of message checked
Key takeaways
- Gmail clips HTML above roughly 102 KB, counting the source, so repeated styles and embedded images matter more than how short the message looks.
- Clipping hides the footer, unsubscribe link, buttons and tracking pixel, and gives the sender no warning.
- Measure the worst-case rendered message, set an internal budget well under the limit and fail the build when a template exceeds it.
- Fix it by hosting images, minifying, flattening layout, shortening links and capping long lists.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.


