Measuring Gmail clipping limit

[hteumeuleu]

Yesterday, an interesting conversation was started on the #emailgeeks Slack by @hellocosmin regarding Gmail clipping limit.

Do we have a source for the magic 102KB message size Gmail clipping limit? I'm curious if someone actually tested this or if it was communicated from an official source, as I've been blindly following it (like most of us probably have), and I've recently seen emails that were 99.something KB getting clipped (before you ask, it was after ESP added stuff to it).

A few people, including myself, weighed in to share their experience and a few test results, but without a definitive answer yet. I loved the little collaborative investigation that went on for a few hours, but it seems Slack is not really appropriate for this (given the temporary nature of conversations there). So I thought here would be a good place to continue this together.

The problem

When HTML emails are too large, Gmail clips them with a [Message clipped] notice and a View entire message link. It's been widely shared that this clipping occurs after 102Kb (example: Gmail is clippin my email on Mailchimp). But no one seems to know where this number comes from. And different people have experience different results around the 100Kb mark.

So what is going on exactly? Can we figure out Gmail's clipping algorithm?

[hteumeuleu]

Here are a few tests I ran yesterday.

First tests

My first question was how any of this was calculated. Does Gmail consider ~100Kb after doing all its prefixing and filtering (removing styles and HTML tags it doesn't support, converting class names and such)? So first I ran this test with 400 tables and 400 style tags.

In this test, the email is clipped at the 181th email. If we try to reproduce this locally by keeping the 400 style tags but only keeping 181 tables, we obtain an HTML that weighs exactly 100 Kb (or 99 507 bytes / 102 Kb on drive according to macOS info dialog). Here's the result file of this first test.

To confirm this, I ran a second test without the style tags this time, only the 400 tables. The result shows the email is clipped at the 254th table.

By reproducing this locally (and only keeping 254 tables), I can measure the weigh of the file to be 100 Kb (or 99 906 bytes / 102 Kb on drive according to macOS info dialog). Here's the result file of this second test.

Finally, I ran a third test with 400 tables, each with an HTML data attribute on each <td> (<td data-a-very-long-attribute-that-gmail-will-filter="true">). This should confirm whether Gmail measures the weight before or after any filtering.

The result shows the email is clipped at the 223rd table. But interestingly, the dummy text is clipped right after the first word. Here's the code of this table as seen in Gmail in Chrome by inspecting the code.

<table border="0" cellpadding="0" cellspacing="0" width="100%">
	<tbody>
		<tr>
			<td class="m_320685387637992867style223">
				<h1>223</h1>
				<p>
					Lorem </p>
			</td>
		</tr>
	</tbody>
</table>

If we reproduce that exact same email locally (with only 223 tables and the text clipped at the first word at the end), we obtain a file that is once again exactly 100 Kb (or 100 217 bytes / 102 Kb on drive according to macOS info dialog). Here's the result file of third test.

First observations

Here are the first observations that I draw from these three tests:

• The weight considered by Gmail for clipping is before any filtering or prefixing happens. So we can use the weight measured in our OS as an indication.
• My three tests return the email clipped at slightly different weights, but always at the exact same weight "_on drive" (102 Kb on drive according to macOS info dialog).

[revelt]

Thank you for sharing!

It's definitely not exactly 100KB, I've seen crop happen at lesser sizes. My "rule of thumb" has always been to aim at file sizes less than 80KB. 1 character = 1 byte so that's around 80,000 characters, what's easy to check in the code editor if you select-all and see the status bar for total character count.

What's also interesting, if you consider, Gmail will receive not your HTML but what ESP sent it, basically, what you see in the "message's raw source". Various factors will bloat the served HTML code in there: ESP link URL scrambling, quoted printable encoding, sometimes ESP's serve message as BASE64-encoded...

So, maybe 100 could be the threshold, but definitely uppermost and very possible in the shape of 100x1024 characters in the raw source in the HTML part of the message, as received by email server. But I'd aim for less than 80,000 characters in source HTML.

[hellocosmin]

Here's the third test file in Windows:

Differences are to be expected, and I think neither are true to what Gmail actually counts server side, as @revelt pointed out.

On this note, I'd encourage taking tools that test your HTML file size against 'Gmail's limit' with a grain of salt. The point is 'we don't know exactly yet', so apparently useful tools might be a little misleading. It can happen they're just a tiny bit off, but that can be the difference between your tracking pixel being removed in all Gmail clients, or not.

Here's the thrid test file that was clipped, in the tool I linked to above:

[revelt]

Very very cheeky

[hteumeuleu]

@hellocosmin You tested the file after clipping. So isn't the tool actually accurate to show that it will pass Gmail clipping? If I test the original file, it indeed says the email is too big (at 175.869140625 Kb).

@revelt Good point on being careful with manipulations done on the ESP side. I used Putsmail for all my tests, which is pretty safe as far as I know.

[hellocosmin]

Indeed Rémi, I've tested the same third result file. You mentioned macOS reported to be 102KB on disk.

So an HTML that you'd think would very likely be clipped (according to macOS' report) was actually reported as 'safe'. Even if we don't consider 'on disk', and we take it to be 100KB, the difference is still large enough to be misleading: there's a 2,1318359375KB difference at the very least, so logically I can imagine a ~103.13KB file as also being reported 'safe'.

My point was we should take such file size weighing tools as estimates, and definitely not fully trust some JavaScript that calculates text file size as being the same thing Gmail does when deciding to clip :)

[pbiolsi]

From your testing/understanding, what do we know about how/if images impact the calculable email weight by Gmail?

Since we're all serving images through some external server or CDN, I've always assumed that their size only had an implication on bandwidth/loadtime... but perhaps that is incorrect and the Gmail image cache is at all to blame for clipping?

Our embedded styles run pretty lean (so not triggering the CSS characters limit) and we use built-in minification provided by our ESP (Listrak) at the time of send to remove whitespace. Yet, we still see emails as small as 32kb getting clipped by Gmail.

Any possibility they impose a pixel height-based limitation that could be triggering that? Like Outlook has been known to?

[hellocosmin]

Never saw emails that small being clipped in Gmail, and I sent quite a few that were larger than 32KB. You sure your ESP isn't adding stuff to what Gmail receives?

[revelt]

@pbiolsi check the raw source. I'm pretty sure Gmail is measuring raw source. Now, if message is multipart, there's Base64 with some heavy link scrambling, sizes will bloat significantly..

1 character in your email's raw source = 1 byte. That includes escape characters (used in quoted-printable encoding for example). After you rule-out the raw source, then move to images.

Sizes as low as 32KB should not get clipped, something's wrong here

[pbiolsi]

@hellocosmin @revelt great points about the ESP bloat, however I've actually seen this in Litmus previews using the Chrome extension (so serving local source pre-ESP... also un-minified in this case). Maybe something else is causing this from the Litmus side, but I believe those previews use PutsMail so should be pretty true to source.

I'll investigate more and post back.

[hteumeuleu]

Last week on the #emailgeeks Slack, @M-J-Robbins shared an interesting example that gets clipped because of a special character.

Just got an email through that Gmail said was clipped but the code is tiny and no obvious errors.

This is the character in question `` (not sure if slack will auto convert that) but I believe it’s this one https://unicode-table.com/en/0092/

Here’s an html example https://litmus.com/scope/ajulzityfxh6

<html>
  <p>�you�re</p>

This only happens on the new Gmail redesign, not on the old one. This is very interesting because I also noticed a lot of emails getting clipped for no apparent reason since the redesign. I'll try to see if there are more characters triggering this.

[ericlepetit]

Funny enough the Github email notification for this message was clipped on Gmail :)
I will bring this up to the Gmail team.

[revelt]

hi all, just crossposting here from email geeks slack for posterity because this is surfacing up once in a while. If you want to check, does your email contain any non-ascii characters (like Unicode's culprit "Private Use Two" above), I created a CLI app (terminal app) for that: https://www.npmjs.com/package/email-all-chars-within-ascii-cli