You spent twenty minutes finding the perfect header image. You exported it at high resolution because you want it to look crisp. You embedded three more throughout the body to break up the text. And now your open rates are down 14% and you’ve no idea why.
Images aren’t neutral. Every kilobyte, every file format choice, every decision about hosting affects whether your newsletter reaches the inbox—and whether anyone bothers reading it once it arrives.
The weight problem nobody talks about
Email clients don’t wait for heavy emails. Gmail truncates messages over 102KB, clipping everything below that threshold behind a “view entire message” link. Apple Mail on iOS often fails to load images over cellular connections when the total payload exceeds certain thresholds. Outlook still renders images inconsistently depending on file size and format.
But the real damage happens before any of that. Spam filters look at email size as a signal. A 600KB email with multiple high-resolution images patterns-matches with the kind of promotional blasts that recipients ignore. It doesn’t matter that your content is thoughtful and your list is engaged. The structure of your email is whispering “bulk sender” to every filter between you and the inbox.
Most newsletter operators export images at whatever size their design tool suggests. That’s usually 2x or 3x resolution for retina displays—which means a 600-pixel-wide image ships at 1800 pixels and gets scaled down by the email client. You’re sending triple the data for zero perceivable quality gain in an email context.
Alt text isn’t just for accessibility anymore
Roughly 43% of Gmail users have images blocked by default. Apple Mail Privacy Protection loads images through a proxy that strips tracking pixels but doesn’t guarantee the image itself renders on the user’s screen if they’re skimming with images off.
If your newsletter relies on images to communicate key information—your call-to-action is a button graphic, your main point is in an infographic, your brand identity lives in a masthead—then nearly half your readers see broken boxes and alt text. Except most newsletter operators write alt text like this: “Image” or “Header” or nothing at all.
Alt text is now doing double duty. It’s an accessibility requirement and a reading experience for a massive segment who’ll never enable images. Write it like you’d write a caption: descriptive, useful, complete. If the image disappeared tomorrow, would your reader still understand the email? If not, the image is doing structural work that belongs in HTML text.
Hosting images inline vs. external links
You have two choices: encode images directly into the email (Base64 embedding) or host them externally and link to them. Both have costs.
Base64 increases email size by roughly 37%. A 100KB image becomes 137KB of encoded text embedded in your HTML. That pushes you toward clipping thresholds faster and makes your email source code a bloated mess that some spam filters flag as suspicious.
External hosting keeps the email lightweight, but introduces dependencies. If your image host is slow, the email feels slow. If your CDN goes down, your images disappear. And every externally hosted image is another DNS lookup, another HTTP request, another opportunity for something to break on a flaky mobile connection.
The correct answer isn’t one-size-fits-all. Small logos and essential brand elements can be embedded if they’re optimized under 20KB. Everything else should be externally hosted on a fast, reliable CDN with aggressive caching. If you’re just getting started and need dependable infrastructure that won’t collapse under traffic, BigScoots is worth considering for hosting your asset library.
What actually works
Start with this assumption: your newsletter should be fully readable with images off. Everything else is enhancement.
Optimize every image before it goes in. Use tools like ImageOptim or Squoosh to compress without visible quality loss. Export at 1x resolution, not 2x—email clients aren’t photo galleries. For photographs, use JPEG at 60–80% quality. For graphics and logos, use PNG-8 when possible, not PNG-24. SVG works in some clients, but support is inconsistent enough that you’re better off sticking with raster formats.
Keep total email size under 80KB including all images and HTML. If you’re regularly exceeding that, you’re either embedding too much or not compressing aggressively enough.
Test your newsletter with images disabled in Gmail, Apple Mail, and Outlook. If it’s unreadable or confusing, restructure. Move key content into text. Use images to support, not replace, your message.
And for the love of deliverability, stop using a giant hero image at the top of every send. It’s a pattern spammers love, it increases size, and it trains readers to scroll past the first screen before they see anything substantive. If you must use one, make it small, make it fast, and make sure your first paragraph of real text loads above it.
If this changed how you think about images in your sends, reply and let me know what you’re adjusting. I read every response, and your questions shape what we cover next.
Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.