The 102KB Clip: Gmail’s Truncation and the Craft of the Front-Loaded Issue

Somewhere in the middle of a long newsletter, Gmail draws a line. Below it, the text stops, an ellipsis appears, and a small link offers View entire message. The reader has not been told the issue is too long. They have been told, in the quiet way interfaces tell us things, that the container has made a decision on the writer’s behalf.

This is the artifact I want to examine: not the growth tactic, not the deliverability scare, but the cut itself. It is a named, observable convention in the inbox, and like most conventions it disciplines the content that passes through it. The question for writers is whether we let that discipline happen to us or whether we practice it deliberately.

What the threshold actually measures

Gmail clips messages whose size exceeds roughly 102KB, hiding the remainder behind a View entire message link. That figure comes from platform documentation rather than a Google page I can cite directly here, so treat it as the working number the sending tools use. Mailchimp’s help documentation states the behavior plainly: “Gmail clips emails that have a message size larger than 102KB, and hides the full content behind a ‘View entire message’ link.”

What counts toward that size is the message source — the HTML, the text, the URLs, the tracking parameters, the markup that styles it all. As Mailchimp puts it, “Each letter—or character—of the code is approximately 1 to 2 bytes.” Hosted image files do not count; only the HTML that references them does. This is the first place writers go wrong. Compressing a photograph will not save an issue from clipping. Rewriting the markup that surrounds it might.

The threshold is also approximate in practice. SendLayer’s guide to inbox clipping notes that “senders report clipping a little under 100KB,” and recommends treating 102KB as a rough boundary rather than an exact one. That is a vendor’s caution, not a standard, but it is a sensible one: the number is a design constraint, not a contract.

Two failure modes that look like one

The most useful thing a writer can understand about clipping is that it conflates two separate variables. One is editorial length. The other is code weight. They are not the same, and confusing them leads to the wrong remedy.

SendLayer makes the distinction directly: clipping “is about the message’s file size, not how long the email reads.” A short-looking issue built from deeply nested tables, repeated inline styles, and leftover HTML comments can cross the threshold while a long, plain-text letter never comes close. The same guide describes how email builders “generate deeply nested tables, repeat inline styles on every cell, and leave HTML comments behind. None of that changes how the email looks. All of it counts toward your 102KB.”

This is the platform’s quiet tax on decoration. Every redundant style attribute, every wrapper table that exists because a builder could not imagine otherwise, every tracking parameter appended to a URL — these are bytes the reader never sees and the writer never chose. When an issue clips, the first question is not “what should I cut?” but “what is in here that I did not put there?”

Non-ASCII characters are a smaller but real contributor. Standard characters take one byte each in UTF-8; accented letters, symbols, and emoji take two to four. A single emoji in a subject line is irrelevant. Hundreds of accented characters across a long template are not. This is not an argument against writing in languages that need them — it is an argument for knowing where the weight sits.

The front of the issue as an editorial decision

Here is where the craft begins. If the container will truncate somewhere, the writer’s job is to decide what belongs above the cut before the container decides for them.

Front-loading is often described as a marketing tactic — put the call to action high, lead with the offer. That framing is too narrow. The real question is editorial: what is the one thing a reader must encounter even if they never click View entire message? For a letter, that is the lede. For an essay, it is the argument’s opening move. For a dispatch, it is the sentence that makes the rest worth continuing. The top of the issue is not a billboard. It is the first paragraph, and it should be written as one.

What belongs below the cut is equally a decision. It should be the continuation — the second movement, the supporting material, the invitation to read further. When the cut falls in the middle of a sentence because the markup ran long, the reader experiences an accident. When it falls at a natural break because the writer planned it, the reader experiences a pause. The bytes are the same. The reading is not.

The deliberate “read more” versus the accidental ellipsis

These are two different artifacts, and writers should prefer the first even when they are nowhere near the limit.

Gmail’s ellipsis is an accident of byte count. It appears where the container decided, not where the writer did. A deliberate read more link is an editorial gesture: it has its own opening sentence, its own destination, its own reason for existing. Mailchimp recommends using “Read More links” when content cannot be cut, noting that this is “more obvious than the link Gmail creates.” SendLayer makes a similar case for leading “with a preview and a ‘read more’ link rather than pasting a whole article.”

The distinction matters because the two artifacts teach the reader different things. The accidental ellipsis teaches them that the email was too heavy. The deliberate link teaches them that the writer made a choice about where the issue ends and the next thing begins. One is a failure of craft. The other is craft.

What clipping does to the reader’s exit

There is an ethical dimension here that is easy to miss when the conversation stays on tracking and deliverability.

SendLayer notes that “clipping can also hide your unsubscribe link, which makes recipients more likely to hit the spam button instead.” That is usually framed as a deliverability problem — complaints hurt sender reputation. But it is also an editorial-ethics problem. The reader’s exit should never be concealed by the container’s truncation. If a writer’s issue is so heavy that the unsubscribe link falls below the cut, the reader has been denied the most basic courtesy of correspondence: the ability to leave.

The tracking consequences are real but placement-dependent, and writers should be honest about that rather than repeating a blanket claim. Mailchimp describes open tracking being clipped along with the message. beehiiv’s documentation states that its open-rate pixel sits at the top of the email, so clipping does not affect its open rate — though readers who click through to view the entire message are not tracked as clicks, because the clipping happens inside the mail client rather than through a tracked URL. The lesson is not “clipping always breaks tracking.” It is “know where your pixels and links sit, and do not let the container decide whether they survive.”

A brief historical analogy, offered as analogy

The idea that display environments truncate is older than Gmail. RFC 5322, the Internet Message Format specification published in October 2008, sets two line-length limits: “Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.” The 78-character recommendation exists, the document explains, “to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line.”

Two things are worth noticing. First, the standards have long acknowledged that readers’ software will truncate, and have long declined to dictate what that software does. RFC 5322 says explicitly that it “is not intended to dictate … any of the characteristics of user interface programs that create or read messages.” The container is not the writer’s to control. Second, the response to that uncertainty was to recommend a conservative format — not to demand that readers change.

This is an analogy, not a causal claim. Gmail’s 102KB threshold is not descended from the 78-character recommendation, and I have no evidence that Google’s engineers had RFC 5322 in mind. But the pattern is instructive: format standards have consistently treated truncation as a fact of the display environment and placed the responsibility for the front of the message on the writer. That responsibility has not changed. Only the number has.

MIME, the extension that made rich email possible, was designed with a similar humility. RFC 2045 notes that “compatibility with existing standards AND robustness across existing practice were two of the highest priorities of the working group that developed this set of documents. In particular, compatibility was always favored over elegance.” The container disciplines the content because the container was built to survive, not to be beautiful.

A practical sequence for the front-loaded issue

None of this requires a particular tool or a particular number. It requires a sequence of decisions, made in the right order.

First, measure the rendered HTML. SendLayer recommends saving the rendered template as an .html file and looking at its size, because “this is the number you can actually act on, since it’s the part you control.” Do this before you start cutting words. You may find the words are not the problem.

Second, cut markup before cutting prose. Flatten nested tables. Consolidate repeated inline styles into a single declaration. Remove HTML comments left by builders. Shorten tracking parameters where you can. These changes are invisible to the reader and recover bytes without touching the argument.

Third, decide what the front of the issue is for. Write the lede as if it were the only thing guaranteed to be read, because under truncation it may be. Then decide where the natural break falls and place the deliberate read more link there — not wherever the byte count happens to land.

Fourth, check the exit. Confirm that the unsubscribe link and any essential account information sit above the likely cut. This is not a growth consideration. It is a courtesy.

Fifth, test with the subject line varied. Gmail groups messages sharing a subject line into a single conversation, and SendLayer notes that “if the whole thread grows too large, Gmail clips it.” This rarely affects production sends, but it catches people testing: send the same test subject twenty times and the later copies may collapse under the trimmed section. Vary the subject or clear the thread before concluding that your issue is too heavy.

What the clip is actually for

The 102KB threshold is not a judgment about your writing. It is a container deciding how much of itself to render inline so that the inbox stays fast. That is a reasonable thing for a mail client to do, and it is not going away.

What is within the writer’s control is the shape of the issue that meets that container. A front-loaded issue is not a shorter issue, necessarily. It is an issue whose first movement was written to stand on its own, whose continuation was designed rather than truncated, and whose reader’s exit was kept visible. The container disciplines the content. The craft is in deciding what discipline the content receives before the container applies its own.

Questions writers actually ask

Does the 102KB limit include image file sizes? No. Hosted images load from a server after the email opens; only the HTML that references them counts toward the limit. Compressing an image will not prevent clipping, but removing an unnecessary image tag and its URL will reduce the message size.

Why did my short-looking email clip? Because clipping measures file size, not visible length. A short email built from bloated markup, repeated inline styles, and long tracking URLs can exceed the threshold while a long plain-text letter does not come close.

Does clipping hurt deliverability? Not directly, on the evidence available. The indirect risk is real: a clipped unsubscribe link pushes readers toward the spam button, and complaints affect sender reputation. Treat the exit as the priority.

Can I prevent Gmail from clipping my emails entirely? By keeping the message source comfortably under the threshold, yes — clipping is a size boundary, not a judgment about content. The exact safe margin varies by sender and by the platform’s own reporting, so measure your rendered HTML rather than trusting a single number.

What if I am the one reading a clipped email? Nothing has been lost. Click View entire message and Gmail opens the full version in a new tab. If the culprit is a long thread rather than a single heavy message, turning off conversation view may help.