Measuring Gmail clipping limit #41
Comments
Here are a few tests I ran yesterday. First testsMy 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 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.
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 observationsHere are the first observations that I draw from these three tests:
|
Thank you for sharing! It's definitely not exactly 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 |
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: |
Very very cheeky |
@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. |
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 :) |
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? |
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? |
@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 |
@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. |
Last week on the #emailgeeks Slack, @M-J-Robbins shared an interesting example that gets clipped because of a special character.
<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. |
Funny enough the Github email notification for this message was clipped on Gmail :) |
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 |
Not only have I had issues with emails smaller than 102kb clipping, I've also sent several emails WELL over the 102kb (180-220kb) which don't clip. Anyone have any ideas? Getting a brick wall from Google whenever I try to talk to anyone about it. |
@hthompson82 hi! Do you remember, what was the encoding of your raw messages that arrived into Gmail server (for example, quoted printable, Base64 etc.); did you measure character count in the raw HTML, decoded or the HTML that was put into ESP (former is more interesting); also was the message multipart and if so, how big was text part (hypothesis being text version's content might have affected Gmail clipping limit)? |
@revelt The encoding is "text/html; charset=utf-8". I count the kb size according to how it comes in to my Outlook (since I can't see size in Gmail) so that I can be sure it includes encoding, dynamic data etc. Our test sends are generally multipart but the text version varies between one word ("test") and a couple of paragraphs. Testing without the multipart text version still results in clipping, on the ones which clip. |
@hthompson82 When you say Outlook, do you mean the Outlook web client or do you mean the desktop application that you have to install? If you mean the desktop application, does Outlook let you see the original message? I don't have Outlook installed at the moment so I can't check for myself. But I thought that Outlook would only show you the message source which is the version that Outlook parsed using the Word engine. |
@jkupczak the desktop Outlook app can show you the original HTML source, as it was received. You need to double click the message to open in a new window, then click "Message" in the top left, and then: |
Hi @jkupczak , i use the Outlook desktop app, which includes the size as a column in the inbox. (I also test emails via mail.yahoo.com and hotmail.com in the browser. Plus the various mobile apps on iOS and Android) As an aside, I've also tested compressing the HTML (stripping out all white space) but to no avail. |
This bug mentioned in this thread seems fixed. Can anyone else confirm? |
Got an even shorter example triggering the clipped message being shown because of a special character:
Encoding the copyright character into |
@hteumeuleu I have this issue and I'm using |
Got any information you can share. |
yeah, let's create a minimal case to be able to reproduce.. as they say "He who asserts must prove" |
I think the issue is that the provider I'm using (customer.io) to send the emails is setting the |
Just sent two test emails from Adobe Campaign, one with
|
@hthompson82 I checked the Adobe Creative Cloud newsletter which is allegedly sent from their platform. The encoding in the raw source is
It is not So, to sum up, it seems that Adobe Campaign platform is using a wrong charset to encode their quoted printable, and as a consequence, all non-ascii characters are mangled. All html-encoded characters don't get encoded because they're within ascii so they're fine. |
Here's a weird one: https://m3.news.ubisoft.com/nl/jsp/m.jsp?c=%405nrrN%2BHHqfIXH1q%2FHaFADEvE%2Bv1jGn1Gp%2FMdstPVNaI%3D 19KB email, shown in full, but still showing the 'clipped' message. I checked the source in Gmail web, and even the tracking pixel is there, so nothing was actually clipped... This is what it looks like in Gmail web: |
@cossssmin There's a |
Just re-coded a template for a new client due to clipping. Read through this thread and simply replaced the |
On a related note - AMP for Email recently added a fixed 100kb size limit for emails. Probably is a good indication of what Gmail wants actually wants the 102kb limit to be. |
I just spent half an hour wondering why I got the "Message clipped" on an email. Turns out, I had an HTML comment in french with an accented character (like
|
I encountered this problem when sending email to Gmail from Outlook. Sending a message with any German characters, such as "Grüsse", would cause the message to clip in Gmail. I fixed this problem by making sure my email was encoded as UTF-8, which can be set in the Outlook settings. |
Yesterday, an interesting conversation was started on the #emailgeeks Slack by @hellocosmin regarding Gmail clipping limit.
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 aView 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?
The text was updated successfully, but these errors were encountered: