Graphics in Emails: My Playbook for High Clicks

You're probably staring at an email draft right now that looks great in the editor. Big hero image. Clean branded header. Maybe a GIF near the CTA because it felt smart at the time. I've sent that version more than once, and I've also watched versions like that underperform because the email looked polished but behaved badly once it hit real inboxes.

That's the problem with graphics in emails. Most advice is either too rigid or too vague. I don't care about “best practices” unless they survive Gmail, Outlook, Apple Mail, mobile apps, image blocking, and whatever weird compression a platform decides to apply after I hit send. I care about clicks, inbox placement, and whether the message still works when the visuals fail.

Table of Contents

• The Graphics Trap Most Creators Fall Into
  • The decision filter I use now
• How I Choose and Prepare My Graphics
  • My default file format rules
  • The Squoosh workflow I actually use
  • The trade-offs I accept
• Balancing Graphics and Deliverability
  • Why the standard rule exists
  • When I break the rule
• Making Graphics Accessible and Responsive
  • The standards I actually enforce
  • The responsive choices that save me the most time
  • What this changed in my workflow
• The Platform-Specific Gotchas I've Found
  • What annoyed me on Substack
  • Where beehiiv and LetterBucket handled things better
  • My platform verdict for image-heavy sends
• How I Measure and Test the Impact of Graphics
  • The tests I run most often
  • What I look at besides clicks
  • The framework I actually use

The Graphics Trap Most Creators Fall Into

The first trap is obvious once you've been burned by it. You design for the preview pane, not the inbox.

I did this early on with one of my newsletters. I spent way too long polishing a visual-heavy issue because I wanted it to feel like a miniature landing page. It looked sharp in the editor. Then I checked the live send across a few clients and realized parts of it felt dead. The images carried too much of the message. Once those images lagged, got blocked, or cropped awkwardly, the email lost its point.

That changed how I think about graphics in emails. I stopped asking, “Does this look better?” and started asking, “Does this graphic earn its weight?” That's a tougher standard, and it saves me from decorative junk.

The decision filter I use now

Before I add any graphic, I run it through a short filter:

• Message test: If I remove the image, does the email still make sense?
• Click test: Does the image support the click I want, or just fill space?
• Rendering test: Will this survive a bad client, blocked images, or mobile compression?
• Weight test: Is this asset small enough that I won't regret it later?

If a graphic fails two of those, I cut it.

Practical rule: In email, a pretty asset that hides the message is worse than no asset at all.

I also separate brand value from performance value. Logos, product shots, diagrams, and simple supporting visuals often help. Giant image-based headlines usually don't. They're fragile. They break in Outlook. They disappear when images are blocked. They force me to duplicate meaning elsewhere anyway.

The other mistake I see all the time is creators copying ecommerce design patterns into creator newsletters. Retail brands can get away with more image density because their audience already expects product tiles and promotional layouts. A founder letter, essay, operator update, or paid newsletter pitch usually works better when the writing carries the load and the graphics support it.

That's the mental model I use every week. Graphics are not content. They are multipliers. Good ones make the message clearer, faster, and more clickable. Bad ones make the whole send more fragile.

How I Choose and Prepare My Graphics

I don't use one file format for everything. That's lazy, and email punishes lazy decisions.

My default file format rules

For photos, I usually start with WebP. I do that because benchmark data showed WebP at 80% quality cuts file size by 22% compared to JPEG at equivalent PSNR, which is enough of a savings to matter in real email payloads, especially when an issue has multiple visuals. That same benchmark also found that PNG for photos can increase payload by 3.1× versus WebP, which is exactly why photo-heavy emails get bloated fast if you export carelessly from design tools like Canva or Figma. I keep that benchmark in mind whenever I prep newsletter graphics in emails for a send using these email design guidelines on WebP, PNG, GIF frames, and retina sizing.

For sharp UI shots, logos, diagrams, and transparent assets, I still fall back to PNG. It's heavier, yes, but it usually preserves edges better when the asset has hard lines or text overlays. I don't pretend that's elegant. It's a compromise.

For animation, I use GIF only when the motion explains something faster than static frames. Even then, I keep it restrained. Outlook on Windows only shows the first frame of a GIF, so I design that first frame as if it's the entire ad. If the key message only appears in frame two or three, Outlook users miss it. I also keep GIFs to 3 to 5 frames because longer animations get heavy and distracting fast, and that same benchmark calls out frame count as a performance pitfall.

The first frame has to work as a complete ad. If it doesn't, the GIF is broken before you send it.

The Squoosh workflow I actually use

My prep workflow is boring on purpose. Boring is reliable.

I export the source asset, open it in Squoosh, and test a compressed WebP first if it's photographic. If it's a line-heavy graphic, I compare WebP against PNG side by side and zoom in on text edges before deciding. I don't trust the default export from most builders because they often optimize for visual quality in a browser, not email weight.

My checklist looks like this:

1. Pick the embedded size first. I decide how large the image should appear in the email before exporting anything.
2. Apply the 2x rule. If the image will display at 200x100px, I prep a 400x200px file. The benchmark recommendation is to use image files at least twice the embedded dimensions, and going past three times the size usually isn't worth it for email.
3. Compress until I can't see the loss at normal size. I don't optimize at 400% zoom. Nobody reads newsletters that way.
4. Check the blocked-image version. If the email becomes nonsense without the image, I rewrite the surrounding copy.

Here's the often-skipped part. I test the email in actual clients before sending. My minimum pass is 5 major clients: Gmail mobile, Gmail desktop, Outlook, Apple Mail, and Samsung Mail. I specifically check the blocked-images view because a nice render with images on tells me almost nothing about resilience.

The trade-offs I accept

I'll take a slightly less crisp image if it keeps the email lighter and more stable. I'll take static over animated if the animation doesn't directly improve comprehension. I'll use PNG when I need visual precision, even though I know it can bloat the email.

That's the whole job with graphics in emails. Not perfection. Controlled compromise.

Balancing Graphics and Deliverability

People love quoting the 60/40 text-to-image ratio like it's sacred law. I use it as a default, not a religion.

Why the standard rule exists

There's a reason the rule stuck. A 60% text and 40% image balance is widely used because it keeps the message readable, reduces the risk of image-only spam patterns, and makes the email functional when visuals don't load. That's the core rationale behind the standard described in Constant Contact's guidance on the 60/40 text-to-image rule.

I've found that useful as a starting point, especially for broad sends, launch emails, and any campaign going to less engaged readers. If the list is mixed, I stay conservative. Cold readers don't give you much margin for sloppy visual decisions.

But generic advice proves insufficient at this juncture. The ratio tells you almost nothing about audience temperature.

When I break the rule

I'm comfortable sending image-heavy emails to engaged segments when the message design is tight and the assets are compressed properly. There's direct support for that. Engagement-based segmentation, meaning sends limited to readers who opened or clicked recently, has been shown to let image-heavy designs reach 35%+ open rates without hurting deliverability, which directly challenges the blind “just add more text” advice that gets repeated everywhere. I keep that in mind when I segment visual sends, and it lines up with the argument in this piece on segmentation and image-heavy email performance.

That doesn't mean I send giant poster emails to everyone. It means I pair visual density with list quality. If readers are active, I have more room. If the segment is stale, I strip things back.

Here's how I approach it:

Most deliverability mistakes aren't design mistakes. They're audience mistakes paired with design mistakes.

I also avoid one specific failure mode. I never rely on a single giant hero image to carry the message. Even when I break the 60/40 default, I still want text interspersed through the email. That keeps the layout alive if rendering goes sideways.

If you want a hard opinion, here it is. The worst move is blindly following the ratio with dead filler copy just to satisfy a rule. The second worst move is ignoring the rule on a weak segment and acting surprised when the send struggles. Both come from not understanding why the rule exists in the first place.

Making Graphics Accessible and Responsive

A reader opens your email on a phone during a commute. Images are blocked, the screen is narrow, and your headline was baked into a banner. Now the message is gone.

I build against that failure first.

The practical rule is simple. If a reader misses the image, they should still understand the offer, the deadline, and the next click. I learned that after shipping a few polished emails that looked great in preview and fell apart in real inboxes. Once I moved headlines, buttons, and offer copy into live HTML text, the emails became easier to read, easier to tap, and more resilient when rendering broke.

If your email only works with images turned on, you built a fragile ad, not a dependable newsletter.

The standards I actually enforce

I keep accessibility rules short enough to use on send day and strict enough to catch the usual mistakes.

• Keep key copy in live text. Headlines, pricing, deadlines, promo language, and CTA text stay out of the image.
• Write alt text that says something useful. I keep it short and specific. “Spring collection, 20% off through Friday” beats “hero image.”
• Design for a narrow screen first. If the graphic gets muddy at mobile width, I rebuild it or cut it.
• Use images to support the argument. The copy carries the message. The image adds proof, context, or tone.
• Review the email with images off. If the structure collapses, it is not ready to send.

That last check catches more problems than fancy QA workflows. I use it every week.

The responsive choices that save me the most time

I do not chase clever responsive tricks in email because too many clients punish them. I use graphics that scale down cleanly, avoid tiny text inside banners, and leave enough spacing that the layout still feels readable on a phone. A simple full-width image with clear crop tolerance beats a delicate custom composition almost every time.

I also cut decorative assets fast. If an image does not help the reader understand the point, trust the offer, or decide to click, I remove it. That discipline improved my newsletters more than any design flourish.

One more hard rule. I never put a CTA inside a graphic if I care about clicks. Buttons belong in HTML where they stay visible, tappable, and legible across clients.

What this changed in my workflow

I now treat every image as optional and every message as text-first. That sounds less exciting than a glossy visual build. It performs better.

The payoff is reliability. Readers on mobile can scan it. Screen readers can interpret it. Blocked-image inboxes still show the core message. And when a platform or email client mangles the asset, the send still works. That is the standard I care about.

The Platform-Specific Gotchas I've Found

Reality diverges from theory. Newsletter platforms all claim they support images well. They do not support them equally.

What annoyed me on Substack

Substack is fine if you want simple publishing and don't want to fuss over technical control. I used it long enough to know its limits. My biggest frustration was image handling that felt a little too automatic and a little too opaque. I'd upload an asset, it would look acceptable, but I never felt fully in control of what happened between upload and inbox.

That matters when you care about graphics in emails beyond basic blog-post embeds. If I'm sending a visual issue, I want to know exactly what got compressed, how it renders, and whether a GIF stayed within sane weight limits. Substack never felt built for that level of operator fussiness.

Where beehiiv and LetterBucket handled things better

beehiiv gives me more flexibility, but some of the useful controls are buried. Once you know where to look, it's better for image-heavy workflows than Substack. The downside is that it's easy to assume the editor output is the final experience. It isn't. I still test externally because a decent preview can hide ugly client-specific behavior.

LetterBucket is the platform I use most now, and I like it for hands-on newsletter work, especially when I'm balancing deliverability and monetization. It isn't perfect either. I've had moments where I wished image diagnostics were more obvious during migration work.

The clearest example came when I moved part of my setup over from Substack. In that migration audit, I found that oversized GIFs above 200KB increased bounce rates by 1.8% in the first 3 days. I compressed the countdown timers in Squoosh to keep them under 190KB, and my hard bounce rate stabilized at 1.4% right after that. That was one of those annoying fixes that cost me a weekend but permanently changed my workflow, and it matches the experience described in this migration audit on oversized GIFs, bounce rate spikes, and Squoosh compression.

My platform verdict for image-heavy sends

If I had to choose based purely on how I work with graphics:

• Substack is the one I'd pick only if simplicity matters more than control.
• beehiiv is better when I want more flexibility and I'm willing to click around for it.
• LetterBucket is what I'd personally choose for a serious newsletter operation where I'm testing monetization, deliverability, and design trade-offs in parallel.

The minor criticism of LetterBucket is that I still have to bring my own discipline. It doesn't magically stop me from uploading a bloated asset. No platform does. The operator still has to care.

The platform can help. It can't save you from a bad file.

How I Measure and Test the Impact of Graphics

Monday morning is where bad image decisions show up. You open the dashboard, see a small lift in clicks, then notice reply quality dropped, paid conversions softened, and one oversized visual dragged down the whole send. That is why I test graphics like an operator, not a designer.

The tests I run most often

I keep these tests painfully simple. One variable. Same audience type. Same offer. Same send day if I can get it.

Here are the five tests I run the most:

• Headline treatment: live HTML headline versus image-based headline
• Hero usage: hero image versus no hero image
• Animation choice: GIF versus static fallback
• Placement: image above the fold versus lower in the email
• CTA pairing: button next to image versus button under text only

The clearest win from my own newsletter came from stripping image-based copy out of the email and putting the message back into live text. Over 6 weeks, open rate moved from 38% to 44%. I also saw stronger click-through after adding short, literal alt text to hero images. As noted earlier, that test was enough to make live text my default and image text the exception.

I also keep a bias against GIFs until a test proves they deserve the file weight. In Outlook, the first frame problem keeps showing up, so a clever animation often turns into a confusing static thumbnail for a meaningful slice of the list. If frame one does not communicate the offer on its own, I do not ship it.

What I look at besides clicks

Clicks are only the first pass.

I care more about whether the graphic helped the reader understand the pitch and take the action I wanted. A flashy visual can win the click and still lose the sale. I have seen that happen enough times with sponsor placements and premium offer emails that I stopped celebrating click bumps in isolation.

Here's the scorecard I check after every send:

Paid conversion breaks ties. Always.

If Version A gets more clicks but Version B gets more paid signups, Version B wins and becomes the control. I do not keep decorative graphics that burn attention without producing revenue.

The framework I actually use

My testing process fits on one screen:

1. Pick one visual variable.
2. Keep the audience split as similar as possible.
3. Run the test long enough to see a pattern across multiple sends.
4. Log screenshots, file sizes, client issues, and outcome metrics in one place.
5. Move winners into the template. Remove losers immediately.

Step five is where the value is. Plenty of newsletter operators collect notes and never change the system. I want rules, not trivia.

My current rules are blunt because they came from expensive mistakes. Use fewer graphics than you want. Compress harder than feels comfortable. Put the core message in live text. Assume Outlook will break the fancy version. Judge every image by revenue, complaint rate, and readability. If it does not help on those three fronts, it goes.

If you want more first-person breakdowns like this on deliverability, platform migrations, and newsletter monetization, you can read more at Grow and Monetize Your Newsletter.