Get Started

Why Gmail Clips Your Emails (and How to Stay Under 102KB)

Published

The “View entire message” trap

You send a rich, well-designed email. It looks perfect in preview. But in Gmail, your reader sees it cut off partway down, with a small link: “[Message clipped] View entire message.” Everything below the cut — including your main call to action and, critically, your tracking pixel — is hidden behind an extra click most people never make.

This is Gmail clipping, and it’s one of the most common and least understood email problems. It isn’t a deliverability failure or a spam flag. It’s a size limit, and it’s entirely avoidable once you know the cause.

Why Gmail clips

Gmail truncates any email whose HTML is larger than roughly 102KB (about 102,400 bytes). Above that threshold, Gmail shows the first ~102KB and hides the rest behind the “View entire message” link. The limit is about the raw size of the HTML file — not the images, which are hosted elsewhere and loaded separately.

The consequences go beyond aesthetics:

  • Your CTA can be hidden. If your primary button sits below the cut, most readers never see it.
  • Tracking breaks. Open-tracking pixels are usually placed near the end of the email. When the end is clipped, the open isn’t counted — so your open rates look artificially low.
  • Personalization and unsubscribe links can be cut. Anything at the bottom of a long email is at risk.
  • It looks broken. A “message clipped” banner signals low quality to the reader.

What makes an email too big

The 102KB budget is about HTML file size, and email HTML is unusually heavy for a few reasons:

  • Table-based layouts are verbose. Email uses nested <table> structure instead of lean CSS layout. See Why HTML Emails Use Tables.
  • Inline CSS repeats everywhere. Because clients strip <style>, styles are inlined onto every element, so the same declarations appear dozens of times. See CSS Inlining in Email.
  • Base64-embedded images. The single biggest offender: embedding an image directly in the HTML as a base64 data URI instead of hosting it and linking to it. A few embedded images can blow past 102KB on their own.
  • Long content. Newsletters and digests with lots of sections naturally accumulate markup.
  • Pasted styles and bloat. Copy-pasting from other tools can drag in redundant markup and comments.

How to stay under the limit

Keeping an email lean is mostly about discipline in a few areas:

  1. Host images, never embed them. Reference images by URL from a CDN or image host so the image weight lives outside the HTML file. This is the single most effective fix.
  2. Keep content focused. If a newsletter is genuinely long, split it or move deeper content behind links. Every section adds markup.
  3. Minify the HTML. Stripping unnecessary whitespace and comments recovers meaningful bytes.
  4. Avoid redundant markup. Clean, consistent structure produces smaller output than deeply nested, hand-tweaked tables.
  5. Trim unused styles. Styles and font declarations that nothing references are dead weight — remove them.
  6. Check the size before sending. Know your HTML’s byte size and keep a margin below 102KB.

Done manually, staying under the limit means constantly watching your byte count and remembering not to embed images — easy to forget when you’re focused on design.

How Temway keeps emails small

Small, clean output is a design goal of Temway’s rendering pipeline, not an afterthought:

  • Images are hosted, not embedded. Temway uploads and references images by URL rather than base64-embedding them in the HTML, keeping the file size down. Even complex visual elements are rasterized and hosted as linked images rather than inlined — specifically to keep delivered HTML well under Gmail’s clipping threshold.
  • Efficient output. Temway produces consistent, structured HTML rather than the bloated, hand-tweaked markup that accumulates over time.
  • Unused fonts and styles are stripped. Font declarations and styles that the final email doesn’t actually use are removed from the exported HTML, trimming bytes and avoiding broken external font requests.

The upshot: the HTML you download, test-send, and push to your ESP is built to stay small and render fully in Gmail — no “message clipped” banner, and your CTA and tracking intact at the bottom.

Where to go next