How To Stop Gmail Clipping By Keeping HTML Under 102KB

Gmail clipping is what happens when an email’s HTML gets too large and Gmail hides the rest behind a “View entire message” link, which can bury key calls to action, footers, and tracking. The practical rule is simple: keep the raw email HTML under 102 KB, because Gmail counts the code itself, including inline CSS, long URLs, and tracking snippets. The fastest fixes are usually to remove extra content blocks, paste text without rich formatting, and trim repeated styles or boilerplate that your template duplicates. The surprising part is how often the “bloat” comes from small, invisible pieces that add up long before your email looks lengthy.

Gmail email clipping explained and why 102KB matters

What users see when an email gets clipped

When Gmail decides your email is too large, it does not show the full message. Instead, it displays the top portion of your email and then stops mid-stream with a notice like “Message clipped” plus a “View entire message” link.

That link feels small, but the impact is big. Many readers never click it. So anything that sits below the cut line is effectively hidden: secondary offers, FAQs, social proof, legal footer, and sometimes even the primary call to action if your template pushes it down.

Clipping is also not “smart” about layout. Gmail clips at a byte limit, not at a clean section break. That means the visible email can end at an awkward spot, like halfway through a module, or right before a button you expected to be seen.

Why clipped emails hurt clicks, trust, and tracking

Gmail’s clipping limit is tied to the size of the HTML code, and the practical threshold most email teams work with is 102KB. Go over it, and your email becomes harder to read and easier to ignore.

Clicks drop for a simple reason: fewer people see the parts of the email you built to earn the click. It can also affect trust. A message that looks cut off can feel broken or unfinished, especially if the clip lands mid-sentence or mid-design.

Tracking can take a hit, too. Open tracking pixels and other tracking elements often sit near the bottom of the HTML, and clipping can prevent them from loading unless the reader expands the message.

This is why tools like Mailscribe focus so much on keeping email HTML lean. Under 102KB is not just a technical guideline. It is a deliverability and performance safeguard.

What counts toward Gmail’s 102KB HTML size limit

HTML and inline CSS that add up fast

Gmail clipping is driven by the size of the email’s HTML code, not how “long” it feels on screen. That means the quiet stuff often pushes you over 102KB:

Inline styles are a common culprit. In many email builders, the same CSS gets repeated on every table cell or paragraph. A few extra characters per element adds up fast across a full template.

Long URLs also count. Every tracked link, image URL, and redirect wrapper is part of the HTML. If your ESP appends long tracking parameters to every link, the code grows even when your content stays the same.

Reusable elements can become duplicate elements, too. Social icon blocks, legal footers, menu bars, and “recommended products” sections are small individually, but they can be heavy in markup when they include lots of nested tables and inline CSS.

Base64 images and embedded assets that bloat code

If you embed images directly in the HTML using Base64 (data URIs), you are literally placing the image data inside the message source. That can explode the HTML size in a hurry, even for a single small image.

The same idea applies to any embedded asset that gets inlined into the HTML. Gmail has to count those bytes because they are part of the code. If avoiding Gmail clipping is the goal, hosted assets are almost always safer than embedding.

What does not count, like hosted image file size

A key nuance: the file size of a hosted image does not count toward Gmail’s 102KB HTML limit, because the image is loaded separately from your server or CDN. What does count is the HTML required to reference it, including the <img> tag, attributes, and the image URL itself.

Many ESPs summarize it well: Gmail clips based on the message’s code size, not the weight of externally hosted images. You can see a clear explanation in AWeber’s guide to Gmail clipping.

How to measure your email HTML size before sending

Getting the HTML size from your ESP editor

Start in your ESP, because many editors expose the HTML size somewhere in the build or preview flow. Look for labels like “HTML size,” “message size,” “code size,” or an export option that shows the file size before you send.

If your ESP does not show it, you can still estimate risk quickly:

Lots of repeated inline styling usually means bigger HTML.
Many content blocks copied from Google Docs or Word often adds hidden markup.
Every tracked link and social icon adds characters, even if the design looks simple.

If you use a tool like Mailscribe, a good workflow is to check size after your final content is in place, not before. Last-minute swaps (extra product grid, a few more links, a long legal footer) are what often push a message over the edge.

Downloading the message source to check KB

The most reliable check is the actual message source, because that is what Gmail evaluates.

A practical method:

Send the email to a Gmail inbox as a test.
In Gmail (web), open the message and use “Show original.”
Copy the raw source into a plain text editor and check the file size, or save it as an .html/.txt file and look at the file’s size in your operating system.

You want the HTML source to stay comfortably under 102KB. Leaving a buffer is smart, since some systems add or rewrite code at send time.

Testing across Gmail web, iOS, and Android

Do not assume one Gmail experience represents all of them. Test the same message in:

Gmail on the web, Gmail on iOS, and Gmail on Android. Clipping behavior can show up differently depending on the app and how the message is rendered.

Keep your pass/fail criteria simple: if you see a “Message clipped” notice or “View entire message,” treat it as a hard warning and reduce HTML before you send to your full list.

Keep email HTML under 102KB with high-impact edits

Remove extra markup, comments, and redundant wrappers

The quickest wins usually come from deleting code you do not need, not “designing smaller.” Email templates often accumulate extra wrappers over time: nested tables inside tables, empty spacer rows, repeated container divs, and leftover modules that are hidden but still present in the HTML.

A few practical, high-impact edits:

Remove unused sections completely (do not just hide them).
Delete HTML comments and builder notes if your ESP exports them.
Watch for repeated “spacer” code. Replace five separate spacer rows with one consistent spacing approach.
Avoid pasting rich text from Google Docs or Word. Paste as plain text first, then style it in the editor. This can eliminate a surprising amount of hidden markup.

If you are working in Mailscribe, a solid habit is to run a “clean pass” after content is final. That is when redundant wrappers and leftover blocks are easiest to spot.

Minify inline CSS and clean unused styles

Inline CSS is necessary for many email clients, but it is also one of the fastest ways to hit the 102KB limit. The goal is not “no styles.” It is fewer repeated styles.

Focus on:

Consolidating repeated style strings. If the same font-family, font-size, color, and line-height appear hundreds of times, your HTML grows fast.
Removing unused classes and declarations. Some builders include a big style block even if you are not using half the components.
Shortening overly specific inline styles. For example, you often do not need to repeat margin:0; padding:0; on every element if your template already resets it in a predictable way.

Minification helps, too. Stripping extra whitespace from style attributes and removing unnecessary line breaks will not fix a bloated template alone, but it can push a borderline email back under 102KB.

Reduce link bloat from tracking parameters

Link tracking is important, but link bloat is real. Every character in every URL counts toward the HTML size, and newsletters can easily have 30 to 100 links.

To reduce bloat without losing attribution:

Remove unnecessary query parameters. Keep only what you actually use in reporting.
Avoid stacking tracking systems (for example, ESP tracking plus an additional redirect layer on every link) unless you truly need both.
Use fewer duplicate links. If your module has an image, a headline, and a button that all go to the same place, consider making just two clickable elements instead of three.

This is one of those changes that does not alter your design much, but it can meaningfully reduce HTML size and lower the chance of Gmail clipping.

Template-level changes that prevent clipping in future sends

Use a lean, modular layout with fewer nested tables

If you are constantly fighting Gmail clipping, the long-term fix is usually the template, not the one-off campaign. Many legacy email templates rely on deep nesting: table inside table inside table, plus extra wrappers “just in case.” It works, but it is expensive in bytes.

A leaner approach is to build a modular layout with a consistent outer structure, then drop in simple modules that share the same grid rules. Keep table nesting as shallow as you can while still rendering well in Outlook and Gmail. You also want to avoid “layout by spacers” where each module adds multiple rows purely for padding.

As a quick rule: if a module needs three wrappers before you reach the real content, it is probably heavier than it needs to be.

Centralize styles and reuse components

Even though inline CSS is still common in email, you can often reduce repetition by standardizing how modules are built.

Good template hygiene looks like this:

One button component, reused everywhere, not five slightly different buttons.
One headline style, one body style, one small-print style.
A consistent spacing system (for example, a small and large padding option), instead of custom padding values on every block.

This kind of consistency reduces HTML size because you are not carrying dozens of unique style strings across the email. It also makes QA faster. When you change a button color once, it changes everywhere, rather than creating more “style drift” that adds weight over time.

Avoid copy-paste content that adds hidden formatting

A lot of HTML bloat is accidental. Copying content from Google Docs, Word, or even another email can bring along hidden formatting and extra tags. The email may look fine, but the underlying code is much larger than it needs to be.

To prevent that:

Paste copy as plain text, then apply formatting in your email editor. If you need to paste a table, rebuild it with your template’s module instead of importing a formatted table from another source. Also be careful when duplicating old campaigns. You may be inheriting years of tiny, unnecessary code decisions.

When your template stays clean, staying under 102KB stops being a scramble and becomes the default.

Content strategies when your email is too long

Move secondary content to a landing page with a Read more link

Sometimes the email is genuinely long because the content is long. In that case, the cleanest way to avoid Gmail clipping is to keep the email focused and move the “nice to have” sections to a landing page.

A simple pattern is a short teaser plus a clear “Read more” link. It works well for:

Product roundups, weekly newsletters, event recaps, and multi-topic updates.

You still give readers value in the inbox, but you stop trying to pack the full article or full catalog into the HTML. This also reduces the number of modules, links, and repeated styles that push you past 102KB.

Split into two sends without duplicating heavy code

If the content must stay in email, splitting can be better than trimming. The key is to avoid sending two heavy emails that both reuse the same bulky structure.

Keep part one and part two on the same lean template. Change only the content modules that differ. Do not duplicate large navigation bars, oversized footers, or “recommended” sections in both sends unless they are truly needed.

Also, be mindful of tracking and personalization. Dynamic blocks can add a lot of HTML. If both emails include multiple dynamic sections, you may still hit the 102KB limit twice.

Keep critical CTA and unsubscribe above the clip point

When clipping happens, Gmail hides the bottom. So design defensively:

Place the primary CTA, key details, and any trust-building elements (like a simple support link or short address line) high enough that they are visible even in a clipped view.

Separately, make sure your unsubscribe link is not buried so deep that it is likely to be clipped. Beyond compliance, it is a user experience issue. If someone wants out, you want that path to be easy to find without extra clicks.

A good habit is to check your test email and scroll until the “Message clipped” point. Anything below that line should be treated as optional, not essential.

Advanced options when staying under 102KB is hard

AMP and interactive patterns that avoid giant HTML bodies

Expandable sections and accordions in email

If your team regularly hits Gmail’s clipping limit, it can be a sign that the email is trying to do too much in one fully expanded layout. One practical way around that is progressive disclosure: show a short summary up front, then let readers expand sections only if they want the details.

There are two common approaches:

With AMP for Email, you can build interactive modules like accordions that expand and collapse inside the inbox. When it works, this lets you keep the initial view tight without stuffing the email with long repeated sections. It also keeps your “above the fold” area focused on the main story and CTA.

The tradeoff is complexity. AMP emails require an additional AMP version of your message, a standard HTML fallback, and careful QA. Support is not universal across email clients, so you still need the non-AMP experience to stand on its own.

Without AMP, you can sometimes create “accordion-like” behavior using HTML and CSS patterns (often checkbox-based). This can reduce visible length, but it does not reliably reduce HTML size, and support varies widely. In practice, these patterns are best treated as a design enhancement, not your primary anti-clipping strategy.

For most teams, the most dependable “advanced” move is still content structure: concise top sections, fewer repeated modules, and clear links to a web page for the full details. Interactive patterns are helpful when you have a strong reason to keep more content inside the email.