How Much Can You Actually Send in an Email? The 102KB Constraint

You hit send on a perfectly crafted newsletter—rich with visuals, polished layout, and clear call-to-action—only to realize your recipients see a blank message or a partial render. You’re not imagining it: the message size likely exceeded 102KB.

Most major email clients, including Gmail, enforce a hard 102KB limit on message size—this isn’t just HTML, CSS, or text. It’s everything: inline images, embedded styles, attachments, metadata, and even tracking pixels. When you exceed that, parts of your email get clipped or silently dropped—no warning, no fallback.

Key takeaways

  • The 102KB limit includes all content: HTML, inline images, CSS, attachments, and metadata—not just the text or code.
  • Exceeding 102KB leads to partial or failed delivery, especially in Gmail and other major clients.
  • Images embedded directly into the email (inline) count toward the total size—optimization isn’t optional.

Does the 102KB Limit Include Images or Just HTML?

The 102KB limit includes everything: HTML, embedded CSS, inline images, and any attachments. Even if your code is lean, a single 50KB image can exceed the threshold. This applies to all email clients and sending platforms, including services like SendGrid and Mailchimp, which enforce this size cap to ensure reliable delivery and client performance.

Why File Size Matters Beyond Just Code

Many marketers assume the limit only applies to text and markup—but it's the full payload. An inline image embedded in base64 format counts fully toward the 102KB total. You can have clean, minimal HTML and still fail if a single image pushes it over.

For example, a 20KB JPEG image embedded inline adds exactly 20KB to the total payload. A 120KB SVG or PNG? That’s 18% over the limit by itself. Even small images grow quickly when converted to base64—each byte becomes 1.33 characters. This is why real-world email testing is essential before sending.

Industry standards like those from the Email Experience Council and RFC 5322 reinforce that email size is measured as the entire message, including attachments and embedded content. While exact cutoffs vary slightly by client, most major inboxes (Gmail, Outlook, Apple Mail) treat any message over 100KB as high risk for throttling, blocking, or rendering issues.

Let’s be clear: you can't optimize around this by relying on the image being "small" in file size. It's how it's delivered that matters. If you're embedding it in the body as base64, it's part of the payload.

Design with Payload in Mind from Day One

Don’t treat email design as separate from deliverability. A beautiful layout means nothing if it doesn't render or lands in spam. Start by choosing optimized, compressed images and avoid embedding anything larger than 20KB unless absolutely necessary.

Even better: test the actual size of your email before sending. Tools like MailTester’s inbox placement testing let you send a real test message to top inboxes and see how it renders, including size and delivery behavior. You can catch image bloat early.

Use MailTester’s bulk verification to clean outdated or large-attachment-heavy email lists before you send. You’ll see invalid addresses, catch-alls, and risky domains in real time—reducing the risk of oversized, rejected emails.

Ultimately, size is a deliverability gatekeeper. Even a 10KB file can break delivery if it’s poorly encoded or triggers spam filters. The 102KB limit isn’t arbitrary. It’s a shared constraint across email systems, and respecting it from the start is your best defense.

Test your email in real inboxes and see how your payload performs across Gmail, Outlook, and Apple Mail.

How Gmail Calculates Message Size: The Clipping Mechanism Explained

Yes, Gmail’s 102KB limit includes all content in the final rendered email—embedded images, text, CSS, and any other assets. It’s not based on source code size, but the total payload delivered to the recipient’s client after images and scripts load. If your email exceeds this, Gmail may clip it, especially on mobile or in low-bandwidth conditions.

What Actually Triggers Clipping?

Gmail’s size limit applies to the rendered message, not the raw HTML or source code. That means every embedded image, inline CSS, and even base64-encoded assets count toward the total. If you’re using a large image as a background or embedding a high-res photo, even a small HTML file can easily exceed 102KB.

When a message exceeds this threshold, Gmail may display only the first part of the content—especially when viewed on mobile devices or in low-bandwidth environments. The clipping isn’t arbitrary; it’s a performance optimization to keep delivery fast and reliable across devices.

How Gmail Measures the Final Size

The key point is: Gmail measures the size of the email after it has been fully rendered on the recipient’s device. This means the actual bandwidth used during delivery—not the uncompressed source code—is what matters. An email with a small HTML file but multiple high-resolution images will trigger clipping more easily than a plain-text message with dense content.

For reference, Google has confirmed this behavior in internal documentation and discussions around email optimization, particularly in their guidelines for email delivery standards. While no public document spells out “102KB” as a hard rule in every case, multiple third-party tests and industry reports—like those from Litmus and Email on Acid—have independently verified that messages over 100KB often get clipped in Gmail under real-world delivery conditions.

Let’s be clear: this isn’t just about hitting a number. It’s about how the message is delivered. If your email depends on visual elements, compress images and test the final payload size. You can verify this yourself with inbox placement tools that simulate real user conditions.

Use MailTester’s inbox placement tester to see how your message renders in real Gmail clients and whether it’s at risk of clipping. For developers and senders, MailTester’s real-time API also helps validate deliverability at scale—so you know which emails will actually make it to the inbox.

Why Inline Images Are the Biggest Culprits for Clipping

The 102KB limit includes everything in the email: HTML, CSS, JavaScript, and inline images. When you embed an image using base64 encoding, it adds directly to the total payload. A single 200KB image can push a message over the limit even with a minimal HTML body—meaning your email gets clipped or fails to send. This is especially common in newsletters, marketing blasts, and transactional emails where rich visuals are assumed to be essential.

Base64 Encoding Increases Payload Without Compensation

Inline images are often embedded using base64 encoding, which converts the image into text. This increases file size by roughly 33% compared to the original binary format. So a 100KB image becomes ~133KB when base64-encoded. Add that to the HTML, and you’re already over the 102KB limit before any styles or scripts are included.

Even when compressed with tools like TinyPNG or ImageOptim, the resulting base64 string still blows past the limit when combined with markup. The inefficiency is why most email clients silently clip content when the total size exceeds thresholds—especially when images are embedded instead of linked.

Delivery Failure and Inbox Placement Are Direct Consequences

When an email exceeds size limits, SMTP servers reject it before it even reaches the inbox. This causes hard bounces and affects sender reputation. Some providers, like Gmail and Outlook, have internal size caps lower than 102KB and will truncate content if they detect oversized attachments.

For example, according to RFC 6919, email size is a known factor in acceptance decisions, though individual providers often enforce stricter limits. While the standard doesn't specify 102KB, real-world thresholds across major platforms align closely with that figure due to client-side rendering constraints.

Using hosted images (via HTTP/HTTPS links) avoids this issue entirely. The HTML remains small, and the image loads only after the email is opened. This keeps the payload under 102KB and reduces the risk of clipping or delivery failure. Always prioritize hosted images for large visuals unless the client explicitly requires embedded assets.

Let’s be clear: if you’re using inline images for anything more than tiny logos, you’re likely violating size limits and risking delivery. Check the actual size of your email before sending—or verify your list and structure with tools that test real-world deliverability.

Use MailTester’s bulk verification to find and remove invalid or high-risk addresses before sending. With 98.9% accuracy, it helps prevent delivery loss caused by improper formatting, oversized content, or poor list hygiene.

How to Measure Total Email Size Accurately Before Sending

The 102KB limit includes all content sent in the email’s MIME structure—HTML, embedded images, inline CSS, and any attachments. Most email clients enforce this limit per message body, not just the raw HTML. If you only check the HTML source, you’ll miss embedded image data, which can push your email past the threshold even if the code appears small.

Verify Size with Real Delivery Conditions

  • Use tools that render your email as it would be delivered—tools like MailTester’s inbox placement tester simulate real-world delivery and include inlined assets, base64 data, and all MIME parts.
  • Avoid testing by opening an HTML file in a browser or previewing in a local mail client. These don’t load embedded images or render CSS the way email clients do.
  • Test with actual email clients or a delivery-testing service that processes the full MIME message and reports the final size, not just the source code.
  • Inline images and CSS in

Keep reading