Gmail clips an email when the message HTML passes 102 KB: the reader sees the top of the campaign and a “View entire message” link, and Mailchimp notes this also cuts the open-tracking pixel so opens go unrecorded. The confusing part is that image bytes are not in that number. Mailchimp states plainly that “changing image dimensions won't change the amount of data because images are loaded from our servers” — the 102 KB counts code, link URLs and tracking parameters, not the JPEG a reader downloads later. So why compress at all? Three reasons that survive the technicality. Inlined images are the exception: any image embedded as a base64 data URI becomes text inside the HTML and counts in full, so a single inlined hero can blow the limit on its own. Long image URLs count, and a CDN URL with resize parameters and tracking appended is a few hundred bytes each — a 40-image campaign pays that 40 times. And image count itself is markup: an image block brings a table wrapper, a link, alt text and style attributes. The practical answer is do both — shrink and un-inline the images, then trim code. Compress first, then check the HTML size in the builder's own preview.