Gmail may clip an email when its HTML message body is around 102KB, replacing the rest with a “view entire message” link. The practical fix is to reduce the delivered markup not the hosted image file sizes and leave room for personalization, tracking parameters, and sending-platform rewrites.
What Gmail clipping affects
Clipping can hide anything near the bottom of the message, including:
- the final call to action;
- legal disclosures;
- unsubscribe and preference links;
- tracking pixels;
- closing content that helps the message make sense.
It also creates an extra step for readers. Even when the hidden content is not legally critical, a clipped campaign feels unfinished.
HTML bytes and image bytes are different
An image referenced by URL is downloaded separately and does not add its full file weight to the HTML body. Compressing a 500KB hero to 200KB improves load speed, but it does not remove 300KB from the email’s HTML.
The HTML budget is consumed by markup, inline styles, embedded CSS, long URLs, repeated attributes, comments, duplicated content, and data embedded directly in the message. Optimize both HTML and images, but measure them separately.
Measure the artifact that is actually delivered
Do not measure only the source template. Your final size can grow when the pipeline:
- inlines Tailwind declarations;
- expands components;
- inserts personalized content;
- rewrites every link for analytics;
- adds provider headers or footer markup;
- duplicates hidden mobile and desktop sections.
Save a test message from the delivery provider or inspect the final MIME/HTML output. Measure its bytes consistently, preferably as UTF-8, and create a warning well below the clipping threshold.
Set a conservative size budget
Do not target exactly 102KB. The commonly reported boundary is approximate in real workflows, and personalization varies. A team might warn around 80KB and fail a build around 90KB, leaving headroom for rewritten URLs and recipient-specific text.
The exact budget is less important than measuring the same post-build stage and preventing quiet growth.
Remove repeated inline declarations
CSS inlining improves compatibility but can repeat long style strings on dozens of cells. Start by simplifying the design system:
- remove declarations that have no effect;
- avoid unique arbitrary values for every block;
- shorten deeply nested component output;
- consolidate identical wrapper tables where safe;
- do not emit empty optional sections;
- keep class names only when responsive rules still target them.
Do not move critical styles back to the head merely to save bytes unless your client matrix supports that tradeoff. Compatibility still comes first.
Delete development-only markup
Compiled emails should not include source maps, framework hydration attributes, debug comments, unused classes, placeholder examples, or editor metadata. HTML comments can be removed except for conditional comments required by Outlook.
Be careful with aggressive minifiers. They must preserve:
- Microsoft conditional comments;
- templating placeholders;
- whitespace that separates inline text;
- empty attributes with accessibility meaning, such as
alt=""; - CSS rules retained for media queries and dark mode.
Simplify tables without breaking layout
Email tables create repeated attributes, but removing them indiscriminately can hurt Outlook. Look for accidental nesting rather than purposeful structure. A wrapper with one row, one cell, no spacing, and no styling may be removable; a table controlling width or a button may not be.
Use reusable components to prevent copied markup from accumulating small differences. Our Tailwind email component guide helps keep patterns consistent.
Avoid duplicate mobile and desktop content
Two complete copies of a hero or navigation block can consume significant bytes. Prefer one fluid block with a small media query. If a show/hide swap is unavoidable, keep the alternate section focused and test what happens when a client ignores the hiding rules.
The email media queries guide shows how to adapt one table structure.
Shorten tracked URLs responsibly
Tracking systems can turn a concise URL into hundreds of characters, repeated across many links. Reuse the same destination when appropriate, avoid redundant query parameters, and inspect the provider’s final output.
Do not use unknown public URL shorteners for sensitive or transactional messages. They can harm trust and deliverability. A branded redirect under a domain you control is a better option when your sending platform supports it.
Split content when the message is genuinely too long
Some newsletters are trying to be full web pages. If optimization still leaves the message large, include a concise summary and link to the complete article, report, or catalog. This often produces a clearer email and a more usable destination page.
Do not hide essential transactional details behind a link merely to save bytes. Receipts, security notices, and core account information should remain complete enough in the inbox.
A practical optimization order
- Measure post-inlining, post-tracking output.
- Remove comments and development attributes.
- Delete unused CSS and empty sections.
- reduce duplicate mobile/desktop markup.
- simplify unnecessary table wrappers.
- shorten repeated inline styles where client-safe.
- minify conservatively.
- remeasure several personalized variants.
- send to Gmail and verify the actual result.
Keep this check in the email development workflow so size does not depend on someone remembering before a major campaign.
Common clipping mistakes
Compressing images and expecting the HTML to shrink. Remote image bytes are separate.
Measuring before link tracking. Rewritten URLs can add substantial markup.
Testing one short recipient name. Personalized content varies.
Removing Outlook comments. A generic minifier can break client fixes.
Treating the threshold as a target. Production output needs headroom.
Frequently asked questions
Is Gmail’s clipping limit exactly 102KB?
Treat 102KB as the commonly observed boundary, not a safe engineering target. Encoding and pipeline transformations make a lower internal budget more reliable.
Do large images cause Gmail clipping?
Hosted images affect download performance but do not contribute their complete file size to the HTML body. Embedded image data and long image URLs do add to the message markup.
Does clipping affect the unsubscribe link?
It can hide a footer link from immediate view if that footer falls beyond the cutoff. Keep compliance content present and make the HTML comfortably smaller than the threshold.
Can minification solve clipping by itself?
Sometimes, but it should be the final step. Larger savings usually come from removing duplicated content, unused styles, and unnecessary markup.
Share with friends