Image optimization for email: formats, sizes, and compression

Quick answer: Image optimization for email means picking a format every client can actually render (JPEG for photos, PNG for graphics and transparency, GIF for simple animation), exporting at 2x your display width for retina sharpness while keeping individual files under roughly 200KB, compressing hard enough to shrink the file but not so hard you see artifacts, and always backing every image with a fallback color, real alt text, and enough live text that the email still works when the images don’t load. WebP and AVIF look better on paper but still break in Outlook for Windows and get mangled by Gmail, so JPEG and PNG remain the safe deliverable through at least 2029.

A designer hands you a hero. Gorgeous moody photo, headline floating on top, a button. You drop it into the template, it looks immaculate in Apple Mail, you fire a test to your phone and it’s perfect, you ship. Two hours later there’s a screenshot in Slack from somebody on the client side who opened it on hotel wifi, and the email took eleven seconds to paint because the hero you exported straight out of the design tool weighed 2.3MB. Or the other version of this story, the one I’ve lived more times than I’d like: the WebP you saved because some web-optimization blog told you it was “97% supported” renders as a broken-image icon in the client’s Outlook 2019, and now you’re explaining to a marketing manager why the launch email looks like it’s missing half its content. That whole category of pain is what image optimization for email is supposed to prevent, and it’s a deeper, weirder problem than the generic “compress your pictures” advice you’ll find on most marketing blogs.

I’ve been building HTML emails for years, and image optimization for email is one of the two or three things that catches people out the most, partly because half the rules that work on the web are actively wrong in an inbox. So this is the long version – formats and which clients secretly break them, the dimensions that survive Outlook, compression that doesn’t wreck your gradients, the Gmail clipping thing everyone explains incorrectly, and an honest read on what the next five years do to all of it. Code where it helps. War stories where they’re relevant. An FAQ at the bottom for the people who skip to the FAQ, and I see you, that’s fine.

Why image optimization for email isn’t the same as web optimization

Here’s the thing that trips up developers coming from the web side. On a website you have basically one rendering target – a browser – and the browser is a good, modern, standards-respecting piece of software. You get <picture>, you get srcset, you get native lazy-loading, you get loading="lazy" and it just works, you get container queries now too. Image optimization on the web in 2026 is close to a solved problem.

Email is not that. Email renders in something like 40 different clients, and every single one of them decided to handle HTML and images a little differently. Outlook on Windows, in its classic form, uses Microsoft Word’s rendering engine – yes, Word, the document program – and the 2007-era version of it at that. Gmail strips and rewrites CSS on a whim and has its own opinions about image formats. Apple Mail is actually excellent, full modern CSS support, the works, which is wonderful right up until you remember most of your audience isn’t on Apple Mail.

Three major points

So when we talk about image optimization for email, we’re really juggling three separate fights at the same time, and they pull against each other:

• File weight. How heavy is the image, how fast does it load, and does it drag your whole email down on a mobile connection. This is the load-speed and deliverability fight.
• Format support. Will this format actually render in the client your recipient is using, or will they get a broken-image box. This is the cross-client compatibility fight.
• Dimensions and sharpness. Is the image crisp on a high-DPI screen without being so oversized it bloats the email. This is the retina-versus-bloat fight.

Optimize for one and you can quietly sabotage another. Crank the resolution for retina sharpness and you balloon the file weight. Pick the format with the best compression and you lose half your audience to broken images. The job is balancing all three, in an environment that’s hostile to about a third of what you’d normally do.

The blocked-image default nobody designs around

One more thing that makes email images structurally different from web images: a lot of clients hide images by default until the recipient clicks “show images” or “display images below.” Outlook does it. Plenty of corporate setups do it as policy. So a meaningful slice of your audience sees your email for the first few seconds – or forever, if they never click – with zero images loaded.

Which means image optimization for email isn’t only about making images light and sharp. It’s also about making the email survive when the images aren’t there at all. We’ll come back to this hard in a later section, because it’s the half of the topic the generic guides skip entirely. And it’s where a lot of real money leaks out.

A quick word on Apple Mail Privacy Protection

Worth knowing, because it changes how you should think about “loaded.” Since iOS 15, Apple Mail Privacy Protection routes every remote image through Apple’s proxy servers and prefetches and caches them – whether or not the recipient actually opened your email. Apple pulls the image at some indeterminate time, sometimes hours after delivery, sometimes not corresponding to a human looking at anything.

For image optimization that has two consequences. One, your “open” data from image-pixel tracking is now unreliable for the Apple Mail chunk of your list, which is a deliverability-analytics problem more than an image problem. Two – and this is the bit people miss – those images get fetched at scale across your whole Apple Mail audience regardless of engagement, so a bloated hero isn’t just slow for the people who open, it’s getting pulled down a lot of times for no engagement at all. Lightweight images are quietly doing you a favor on the back end. Anyway. Moving on.

Best image format for email: JPEG, PNG, GIF, and the WebP trap

This is the section that matters most and the one where the generic pages get lazy. Most of them give you “JPEG for photos, PNG for logos, GIF for animation” and then stop, which is correct as far as it goes and useless the moment somebody asks “well what about WebP, my website uses WebP.” So let’s do the whole map.

The three formats you can actually trust

These render everywhere that matters. This is your working toolkit for image optimization for email and probably will be for years.

JPEG

JPEG is the workhorse. Photographs, gradients, product shots, anything with a wide range of color and tone. It’s lossy, which is exactly what you want for photos because it throws away detail your eye won’t miss and gets the file tiny. The danger is over-compression, which we’ll get to.

PNG

PNG is for the stuff JPEG handles badly – logos with sharp edges, flat areas of solid color, anything that needs transparency. One thing almost nobody mentions: there are two flavors. PNG-24 is the full millions-of-colors version with proper alpha transparency. PNG-8 is an indexed-color version capped at 256 colors, and for a flat two-color logo or a simple icon, PNG-8 is often less than half the weight of PNG-24 with no visible difference. If you’re shipping flat graphics as PNG-24 out of habit, you’re leaving file savings on the table. I do it too sometimes, then catch it in review and feel slightly reckless.

GIF

GIF is for simple animation and not much else now. The 256-color limit makes photographic content look terrible, and it has no real transparency (a pixel is either fully there or fully gone, so a soft drop shadow turns into a jagged white halo). The big email-specific gotcha: classic Outlook for Windows doesn’t animate GIFs at all, it just freezes on the first frame. So whatever your animation is “saying,” frame one has to carry the message and the call to action on its own. Front-load it.

Now the part the web blogs get wrong: WebP, AVIF, SVG

Here’s where I get a little irritated, because there’s a whole genre of “next-gen image formats” articles that treat email like it’s just another browser, and it absolutely is not.

WebP

Google’s format. On the web it’s brilliant – better compression than JPEG, supports transparency and animation, and browser support is effectively universal now. So you’d think it’s a no-brainer for email image optimization too. It is not. Here’s the actual situation:

• Outlook for Windows (the classic Word-engine version, which is still a huge chunk of corporate inboxes) doesn’t support WebP at all. Your recipient gets a broken-image box. Just empty.
• Gmail “supports” WebP by quietly converting it to JPEG before it serves it to you. Fine for an opaque photo. But the conversion strips transparency, so a WebP with a transparent background renders with a solid (usually wrong-colored) box behind it in Gmail.

The compatibility databases will tell you WebP sits around 97% “supported” across email clients. That number is technically true and practically a landmine, because the 3% that breaks includes the exact corporate-Outlook population that’s most likely to matter for a B2B sender, and “supported” includes Gmail’s transparency-killing conversion. I’ve watched a WebP logo with a transparent background ship to a list and come back looking fine in Apple Mail and broken in two different Outlook installs. Not a debugging session I’d recommend.

The honest rule: don’t ship WebP-only to email. If you really want WebP’s compression, serve it through a <picture> element with a JPEG or PNG fallback – but know that ESP support for <picture> is patchy, several drag-and-drop builders mangle it, and the few kilobytes you save rarely justify the fragility. For most production emails, just export JPEG or PNG and move on with your life.

AVIF

Newer, compresses even better than WebP, 15-25% smaller for comparable quality. On the web it’s genuinely exciting. In email it’s a non-starter right now. Apple Mail and Yahoo render it; Gmail and Outlook are partial-to-broken; Microsoft Office still doesn’t support AVIF natively in 2026 and tells you to convert to PNG/JPG. So AVIF is a “watch this space” format for email, not a “use it” format. It’ll probably become viable after WebP does, not before.

SVG

This one’s a shame, because SVG would be genuinely useful for crisp logos and icons at any resolution with tiny file sizes. Apple Mail handles inline SVG fine. But there’s a 2025-2026 problem that’s killing it dead for email: SVG files became a popular phishing vector (you can hide scripts and redirect URLs inside an SVG), and as a result security gateways and email providers are increasingly stripping, blocking, or quarantining SVG. So even in clients that would render it, your SVG might never reach the inbox, or it lands the whole message in spam. Not worth it. Use PNG for your crisp logo and accept the weight.

So, the short read on formats for image optimization for email in 2026: JPEG, PNG, GIF, full stop. The clever formats stay on your website where they belong.

Email image dimensions and the retina problem

File format is half the battle. Dimensions are the other half of image optimization for email, and the retina handling is where people copy a web tutorial and watch it explode in Outlook.

Start with the right base width

Email content sits in a fairly narrow column. The standard, safe content width is 600 to 650 pixels. Most clients are built around roughly 600px, and if you feed a client an image that’s wildly wider than the slot it’s going into, the client resizes it down on the fly – and client-side downscaling tends to look soft and a little mushy. So don’t send a 2400px stock photo into a 600px slot and hope. Size it to the job.

For a full-width hero in a 600px email, your display width is 600px. For a two-column block where each column is 280px, your images are 280px. Simple enough. The complication is retina.

The retina trap (and why the web trick fails in Outlook)

Modern screens – every phone, most laptops, lots of monitors – pack two, three, sometimes four physical pixels into each CSS pixel. So an image that’s exactly 600px wide displayed at 600px looks slightly soft on a retina display, because the screen has more pixels available than the image has detail to fill them.

The web answer is to export the image at 2x (1200px for a 600px slot) and constrain it down with CSS max-width: 600px or width: 100%. The browser packs the extra detail into the retina screen, everything’s crisp, done.

This breaks in Outlook. Classic Outlook’s Word engine ignores max-width. It wants to render the image at its natural size – 1200px – and it’ll happily blow your 600px email out to 1200px wide with horizontal overflow, or do something weird with zoom. I’ve watched a perfectly good layout get wrecked by exactly this because someone constrained a 2x image with CSS only.

The fix is to set explicit width and heightHTML attributes on the image tag (not just CSS), using the intended display size, while the actual file is 2x:

<!-- File is 1200x800 (2x). Attributes tell every client, including Outlook,
     to display it at 600x400. Outlook obeys the attribute. -->
<img src="https://yourcdn.com/[email protected]"
     width="600" height="400"
     alt="Spring collection lookbook"
     style="display:block; width:100%; max-width:600px; height:auto;" />

The width="600" attribute is the part Outlook actually respects, so it scales the big image down to 600px instead of rendering it at 1200px. The CSS width:100%; max-width:600px; height:auto handles the responsive behavior in the clients that do support modern CSS, so the image shrinks gracefully on mobile. Belt and suspenders, and you need both.

srcset in email? Don’t count on it

You’d hope srcset would solve this – serve the 1x image to standard screens and the 2x to retina screens, save the weight where you can. On the web, yes. In email, support is inconsistent enough that I wouldn’t build a campaign on it. Some clients honor it, plenty ignore it and fall back to the src, and the failure modes aren’t worth the debugging time. The 2x-image-constrained-by-explicit-width approach above is less elegant but it’s predictable, and in email, predictable beats elegant every single time.

The retina tradeoff is real – don’t 2x everything

Doubling dimensions roughly quadruples pixel count, which inflates file weight. A 2x hero photo can easily be three or four times the weight of the 1x version. So retina is a per-image decision, not a blanket policy:

• A photographic hero or a product shot where sharpness sells? Worth going 2x.
• A flat-color divider bar, a footer band, a simple background texture? 1x is fine, nobody’s squinting at your footer.
• A logo? Often worth 2x because logos at soft resolution look cheap, and a logo is usually small enough that 2x is still light.

Use judgment. Retina-everything is how you end up with a beautiful, crisp, 2MB email that nobody on cellular ever fully loads.

How to compress images for email without wrecking them

You’ve picked the format, you’ve sized it right, now you make it light. Compression is where image optimization for email earns its keep on load speed, and it’s also where people either don’t compress enough (heavy, slow emails) or compress so hard the images look like garbage.

Lossy vs lossless, fast

• Lossy (JPEG, lossy WebP): throws away data permanently to shrink the file. You can push it hard on photos because the eye is forgiving of photographic detail loss. This is where most of your savings come from.
• Lossless (PNG, GIF): no quality loss, but the savings are smaller, mostly from smarter encoding and reducing the color palette. A good PNG cruncher can still knock 20-70% off a flat graphic by optimizing the color table.

Export, then compress again

Here’s a habit worth building: the export straight out of Figma, Photoshop, or whatever design tool is almost never optimally compressed. Design tools optimize for fidelity, not for the smallest file. So even after you export, run the image through a dedicated compressor. It commonly shaves another 20-70% off with no visible quality difference, which on a hero is the difference between a snappy email and a sluggish one.

Where the quality line is

The thing nobody warns you about: over-compression has its own failure modes, and they’re ugly.

• JPEG pushed too far shows blocky artifacts, especially around sharp edges and text, and muddy detail in busy areas.
• Gradients are the canary. Compress a smooth gradient too hard and it bands – you get visible stripes instead of a smooth transition. If your design has a gradient hero or a subtle color wash, watch it like a hawk after compression. Gradients in email are already fragile (Outlook handles them poorly to begin with), so an over-compressed gradient image is a double whammy.
• JPEG quality 60-80 is usually the sweet spot. Below 60 you start seeing it on most images. Above 80 you’re often just carrying weight you don’t need. But it’s image-dependent – a flat, simple photo survives harder compression than a detailed, high-contrast one, so eyeball the result, don’t trust a single setting blindly.

Target file sizes (the numbers worth memorizing)

People want concrete numbers, so here they are, the ones I actually work to:

• Individual images: aim for 70-100KB. Treat ~200KB as a working ceiling, not a goal.
• Hero images: under ~300KB if the design demands a big, detailed photo, but get there through compression and sane dimensions, not by giving up.
• Animated GIFs: under 1MB, ideally 500KB or less.
• Total email payload: keep the whole thing light enough to paint fast on a phone over cellular. There’s no single magic number. But a campaign where the images collectively add up to several megabytes is a campaign that loads slowly and frustrates people.

These aren’t laws of physics, they’re field-tested guardrails. The point is to have a number in your head so you notice when an image is way over it, because half of image optimization for email is just catching the file that quietly weighs five times what it should.

The compression tools I actually reach for

Quick, honest rundown. Some of these have affiliate programs and I’ll flag where relevant, but I’m only listing tools I’d genuinely use – my whole working reputation is built on not overselling, so a tool I’d skip gets a “skip it.”

• TinyPNG / Tinify – the long-standing default for PNG and JPEG. Smart lossy compression that’s hard to tell apart from the original. The browser version is free for casual use; the API and the Figma/Photoshop plugins are the paid tier and they’re worth it if you’re crushing images all day.
• ShortPixel – strong all-rounder, generous free tier, good if you’re working in WordPress because the plugin handles your media library too. Solid pick for the producer/course-creator crowd who live in WordPress anyway.
• Squoosh – Google’s free, open, browser-based compressor. No account, no upload-to-someone’s-server worry (it runs locally in your browser), side-by-side before/after slider so you can see exactly where the quality line is. I use it constantly for one-off images. It’s free and it’s genuinely good, which is a rare combination.
• ImageOptim – free Mac app, drag-and-drop, runs a stack of optimizers and strips metadata. Great for a final lossless pass on a batch.
• EZGif – the go-to for GIF optimization specifically (frame reduction, color-table tweaking, lossy GIF). Free, browser-based, ugly, works perfectly.

You don’t need all of them. Pick one good lossy compressor for stills and EZGif for animation and you’re covered.

Image weight vs email weight: the Gmail 102KB clip explained properly

This one deserves its own section because almost every article on email size conflates two things that are completely different, and the confusion costs people.

Gmail clips emails. When an email crosses a certain size, Gmail truncates it, hides the rest behind a “[Message clipped] View entire message” link, and – this is the part that stings – it clips at a raw byte count, so it’ll happily cut your email off mid-tag and break the layout below the cut. It also clips your tracking pixel if that sits at the bottom, which wrecks your open data.

The threshold is roughly 102KB. And here’s the bit everyone gets wrong:

Gmail’s 102KB limit is measured against your raw HTML, not your images. Externally-hosted image files do not count toward the 102KB, because they load from a URL at render time. But the image URLs in your code do count, and any image embedded as base64 directly in the HTML counts fully and will blow your budget fast.

Sit with that, because it flips the intuition. You can have a visually image-heavy email with a dozen photos and still be nowhere near the clip limit, as long as those images are hosted externally and referenced by URL. Conversely, you can have a text-light email that gets clipped because a builder generated bloated, redundant HTML and CSS, or because someone base64-encoded the images “to make them more reliable.”

What this means for your image strategy

• Host images externally. Always. Reference them by URL. Don’t base64-embed them into the HTML except in genuinely rare edge cases (a tiny logo for an environment where external images are guaranteed blocked, maybe), because base64 inflates HTML weight, triggers Gmail clipping, and frankly often just gets stripped anyway.
• Keep image URLs reasonable. Long, parameter-stuffed tracking URLs on every image add up against the 102KB. Not usually the main culprit, but worth knowing.
• Aim for under ~90KB of HTML to give yourself margin below the 102KB clip. Measure the actual raw HTML weight – save the email as an .html file and check its size, or use a testing tool that reports it. The “size” your ESP shows you sometimes includes images and sometimes doesn’t, so don’t trust it blindly.

This is one of those distinctions that separates someone who actually understands email plumbing from someone who read three blog posts. If a developer tells you to base64-embed images “for deliverability,” that’s your sign to ask more questions.

When images don’t load: the half of optimization everyone skips

Right, the blocked-image thing I flagged earlier. This is, in my opinion, the most underrated part of image optimization for email, because all the format-and-compression work in the world is worthless if a third of your audience sees a wall of empty boxes.

Images get blocked. By client default, by corporate policy, by the recipient never clicking “show images,” by a slow or failed image-host connection, by an over-aggressive spam filter that strips remote content. Your email has to function with no images loaded. Here’s how you build that resilience.

Real alt text on every single image

alt text isn’t just an accessibility checkbox (though it is that, and screen-reader users genuinely depend on it). In email it’s also the fallback that shows when the image is blocked. A blocked image with good alt text says “Spring Collection – 30% Off This Weekend.” A blocked image with no alt text, or alt="", or alt="image1.jpg", says nothing, and your email looks broken and pointless.

And here’s a trick a lot of people don’t know: in many clients you can style the alt text. Put inline color, font-size, and font-family on the <img>, and when the image is blocked, the alt text inherits that styling. So a blocked hero can still show a large, on-brand, readable line of text instead of tiny default-blue Times New Roman:

<img src="https://yourcdn.com/[email protected]"
     width="600" height="300"
     alt="Spring Collection - 30% off this weekend only"
     style="display:block; width:100%; max-width:600px; height:auto;
            font-family:Arial,sans-serif; font-size:24px; color:#1a2b4c;
            font-weight:bold; text-align:center;" />

It doesn’t work identically everywhere, but where it works it’s basically free polish.

Fallback color behind every background image

If you’re using a CSS or VML background image (a hero band with text on top), set a bgcolor on the cell so that when the image fails, your overlaid text sits on a solid color instead of nothing. And pick that color so the text stays readable on the color alone – white text on a hero photo is fine until the photo doesn’t load and your white text is now sitting on white. I’ve seen that ship. More than once. (I go deep on this in the background-images piece, so I won’t re-litigate the whole VML dance here.)

Text-to-image ratio: don’t build image-only emails

The single biggest resilience mistake is the all-image email – someone designs the whole thing in Photoshop, slices it, and the “email” is just a stack of image slices with no live text. It looks pixel-perfect in the designer’s preview. It’s also a disaster: it’s invisible when images are blocked, it’s heavy, it’s terrible for accessibility, it can’t be translated or have its text resized, and a poor text-to-image ratio is a known spam-filter signal. Filters get suspicious when an email is all picture and no words, because that’s a classic spammer trick to hide text from content scanners.

Rough rule of thumb: keep a healthy balance, somewhere around 60% live text to 40% images as a floor. Your headline, your body copy, your call to action – those should be live HTML text wherever you can manage it, not baked into images. Which leads directly to:

Use bulletproof buttons, not image buttons

An image-based CTA button that doesn’t load is a dead CTA. The whole point of the email – the click – vanishes. Build your buttons with HTML and CSS (the “bulletproof button” pattern, with a VML fallback for Outlook) so the button renders, is clickable, and looks right even with every image blocked. This is image optimization by not using an image, which is sometimes the most optimized choice of all.

Animated GIF optimization (and the alternatives in 2026)

GIFs still earn their place. Video in email is mostly unsupported, so an animated GIF remains the pragmatic way to put motion in an inbox – a product spinning, a before/after, a subtle bit of life on a CTA. But GIFs get heavy fast, and a fat GIF is a deliverability and load-speed problem.

How to actually shrink a GIF

The weight of a GIF comes from frames times colors times dimensions, so you attack all three:

• Fewer frames. Drop the frame rate. 10-15fps is plenty smooth for email motion; you rarely need more. Cutting every other frame (and doubling the frame delay to keep the timing) can roughly halve the weight.
• Limit the color table. GIF caps at 256 colors anyway, but you can often go lower. Fewer colors, smaller file. Flat, simple animations survive a small palette beautifully.
• Kill duplicate frames. If your animation holds on a frame, you don’t need ten identical copies of it – tools can collapse those.
• Keep dimensions sane. A 600×500 GIF is fine; a 1200px-wide animated hero is asking for a multi-megabyte file.
• Add lossy GIF compression. Tools like EZGif have a lossy slider; 20-40% lossy on a GIF cuts real weight with acceptable quality loss.

Front-load the message into frame one (remember, Outlook freezes there), keep it under 1MB and ideally near 500KB, and keep the loop short – 3 to 5 seconds usually reads better than something long and distracting.

The animation formats that aren’t ready for email

There’s a recurring “GIF is dead, use APNG/WebP/AVIF animation” take that’s true for the web and premature for email. APNG, animated WebP, and animated AVIF all compress dramatically better than GIF and support proper transparency and millions of colors. The problem is they inherit the exact same email-support gaps as their static versions – Gmail and Outlook for Windows being the recurring villains, showing a broken image or just the first frame. You can serve them with fallbacks, but you’re back to fragile <picture> territory.

HTML5 video in email is similar: it works in roughly half the market (the Apple clients, basically) and needs a GIF or image fallback for everyone else, so it’s a nice progressive enhancement for the right audience and not something to bet a campaign on.

So in 2026, for animation that has to work everywhere, the answer is still a well-optimized GIF, and GIF optimization is its own little corner of image optimization for email. I don’t love it – the 256-color limit genuinely annoys me on anything photographic – but it’s the pragmatic pick and probably will be until the new Outlook fully displaces the old one.

Testing your image optimization for email (and what the tools cost now)

You cannot QA image optimization for email by looking at it in your browser. Your local Chrome render respects everything – modern formats, CSS backgrounds, max-width, the lot. It will lie to you cheerfully about how the email looks in Outlook. You have to render it where it’ll actually be opened.

Litmus, with the asterisk

Litmus is still the most thorough previewing tool for serious email QA – screenshots across roughly 100 client and device combinations, every Outlook version you care about, the Gmail variants, Apple Mail, dark-mode previews. For catching format-specific breakage (the WebP broken-image box in Outlook, the soft retina image, the over-compressed gradient banding) across that many clients at once, nothing else is quite as comprehensive.

The asterisk is the price, and I’m not going to pretend it isn’t a problem. Litmus was acquired by Validity in April 2025, and in August 2025 they retired the old entry-level Basic plan and moved everyone onto the Core plan at $500 per month – that’s 2,000 previews, 5 user seats, plus a bundle of analytics and personalization features whether you need them or not. Pay monthly across a year and that’s $6,000; the annual plan shaves about 17% off and lands just under $5,000, which is the only mercy in the whole thing. The old small-team tier that ran around $79-99/month is just gone, no monthly replacement. For an in-house team running dozens of campaigns a month, the math still works. For a freelancer testing a couple of emails a week, $500/month to look at screenshots is a hard sell, and I’ve stopped recommending it as the automatic default even though I still pay for it because my client mix earns it back.

One more heads-up if you’ve used it before: Putsmail, Litmus’s free send-yourself-a-test tool, has been retired. It was a handy free way to fire a quick test to your own inboxes for years and it’s gone, so don’t build a workflow around it.

The cheaper and free options

• Mailgun Inspect (the successor to Email on Acid) – comparable rendering coverage, historically around half the Litmus price, the sensible default for small-to-mid teams now that Litmus priced out the bottom of the market.
• The real-hardware test – virtual previews run on virtual machines, and VMs aren’t real devices. If you can keep one actual Outlook desktop install on an old laptop, do it. Mine’s a 2019 ThinkPad running Outlook 2019, and it catches image gaps and DPI weirdness the virtual previews miss. A physical phone with the Gmail app earns its keep the same way.
• The real-inbox test – send the thing to your own Gmail, Outlook, Apple Mail, and Yahoo accounts before you send to the list. Yes, even for small sends. Check specifically: do the images load, are they sharp on the phone, does the layout survive with images blocked (toggle “don’t show images” and look), and is the GIF first-frame carrying the message in Outlook.

My loop: build, compress, preview in Litmus, fix what it flags, send-to-self across the four major inbox types, look at it on the real phone and the real ThinkPad, then send. Adds maybe half an hour. It’s saved me from more than one “the launch email is broken” phone call, and the half hour is always cheaper than the call.

Where image optimization for email is heading: 2026-2030

This is the part most evergreen image articles don’t bother with, and it’s exactly the part that decides whether your templates age well or you’re re-coding everything in two years. I’ll hedge where I’m guessing, because anyone who tells you they know precisely how a Microsoft transition plays out is bluffing.

The new Outlook slowly changes the format math

The big structural shift is the new Outlook for Windows. It’s Chromium-based (Microsoft Edge WebView2 under the hood), which means it finally behaves like a real browser – modern CSS works, backgrounds work, and crucially for this topic, it supports WebP. So as classic Word-engine Outlook’s share shrinks, the calculus on next-gen formats slowly tilts.

But “slowly” is the operative word, and the timeline keeps getting pushed:

• The new Outlook has been rolling out as the default for new installs, with an opt-out phase where users get it automatically but can revert to classic. That phase timing has been moved more than once, with enterprise environments getting extended lead time.
• The cutover phase – where you can no longer switch back to classic – has no firm public date and won’t land before roughly 2028 for most users.
• Microsoft supports classic Outlook for Windows through at least 2029 for Microsoft 365 subscribers and perpetual-license holders (Office 2021, Office 2024, Office LTSC).

Enterprise IT does not migrate because Microsoft published a roadmap. Banks, government, healthcare, insurance, anyone with a real change-management process – they’ll be opening your emails in Word-engine Outlook for years yet, and that population is exactly your B2B audience, the slow-moving part of the market. So WebP-only emails stay risky through the back half of this decade for any sender with meaningful corporate reach.

My five-year read on formats

• 2026-2027: JPEG/PNG/GIF only for anything with B2B or mixed audience. WebP stays a website format. The Outlook population is too big and too broken on modern formats to risk it.
• 2027-2028: audience analysis starts mattering more than the calendar. A 90%-mobile, consumer, Apple-and-Gmail-heavy list? You can start experimenting with WebP-via-<picture> and trimming legacy weight. An enterprise B2B list? Not yet.
• 2028-2030: as classic Outlook finally fades, WebP becomes a reasonable default with a JPEG fallback for the long tail, and AVIF starts being worth testing. The format conversation actually loosens up.
• Beyond 2030: assuming Microsoft doesn’t pivot again (they might), email image optimization starts to look more like web image optimization, with next-gen formats as the norm and fallbacks as the legacy layer.

A few other moving parts

• AVIF likely follows WebP into email viability, not before it. Watch, don’t deploy.
• Privacy proxies (Apple’s MPP, and Gmail’s image caching) keep making “image loaded” a weak engagement signal, so optimization stays about UX, deliverability, and load speed – not about open-tracking, which is increasingly unreliable anyway.
• SVG stays a security liability for email regardless of rendering improvements, because the phishing-vector problem is about gateways blocking it, not about clients rendering it. Don’t expect that to ease up soon.
• AI-driven inbox features and “dark mode everywhere” keep raising the bar on resilience – your images need to survive color inversion, aggressive prefetching, and clients reformatting your content. The defensive habits (fallback color, real alt text, sane text-to-image ratio) only get more valuable.

The pragmatic recommendation

Ship JPEG, PNG, and GIF today. Keep your high-resolution source files so you can re-export to WebP or AVIF the moment your own analytics say it’s safe. Audit your audience’s email-client mix quarterly – once classic Outlook drops below about 5% of your opens, you can start being more aggressive with modern formats in new templates. Don’t rip working image code out of templates that already work just because a format feels old. And test in real Outlook, not just the caniemail percentage.

That’s the whole philosophy of image optimization for email in one paragraph: optimize for the worst case, keep your originals, and let your data tell you when the worst case stopped mattering.

Frequently asked questions

What is the best image format for email?

For reliable cross-client rendering, use JPEG for photographs and anything with lots of color or gradients, PNG for logos, icons, flat graphics, and anything needing transparency, and GIF for simple animation. These three render correctly in every major email client, and they’re the foundation of any sane approach to image optimization for email. Avoid WebP, AVIF, and SVG as your primary format in email – WebP breaks in Outlook for Windows and loses transparency in Gmail, AVIF has spotty support, and SVG is increasingly blocked by security gateways. JPEG and PNG remain the safe deliverable through at least 2029.

Does WebP work in email?

Not reliably. On paper WebP shows around 97% support across email clients, but that number hides two real problems: classic Outlook for Windows shows a broken-image box because it doesn’t support WebP at all, and Gmail silently converts WebP to JPEG, which destroys transparency. If you want WebP’s compression, serve it through a <picture> element with a JPEG or PNG fallback – but ESP support for that is patchy, so most production emails skip WebP entirely and just use JPEG or PNG.

What size should email images be?

Use a content width of 600 to 650 pixels for full-width images, sized to the actual slot they fill rather than oversized. For sharpness on retina screens, export at 2x the display width and constrain it with explicit HTML width and height attributes. On file weight, aim for 70-100KB per image, treat 200KB as a working ceiling, keep hero images under about 300KB, and keep animated GIFs under 1MB (ideally 500KB or less).

How do I make email images sharp on retina screens?

Export the image at 2x its display dimensions – so a 600px-wide slot gets a 1200px-wide file – then set the HTML width and height attributes to the intended display size (600px), not the file size. The 2x file gives retina screens the extra pixels they need for sharpness, and the explicit width attribute forces clients like Outlook to scale it down correctly instead of rendering it at full 1200px and blowing out your layout. Add CSS width:100%; max-width:600px; height:auto for responsive behavior on top.

Why does my image break or look blurry in Outlook?

Three usual suspects. One, you used a format Outlook for Windows doesn’t support, like WebP – that’s the broken-image box. Two, you constrained a 2x retina image with CSS max-width only; Outlook ignores max-width and renders at full size, blowing out your layout – fix it with explicit width/height HTML attributes. Three, the image is soft because it wasn’t exported at 2x for high-DPI screens, or because a client downscaled an oversized image. Classic Outlook runs on Word’s rendering engine, so it ignores a lot of modern CSS that works fine elsewhere.

What’s the maximum email size before Gmail clips it?

Gmail clips emails when the raw HTML exceeds roughly 102KB, hiding the rest behind a “View entire message” link. The key nuance for image optimization: externally-hosted image files do not count toward that 102KB, because they load from a URL – but the image URLs in your code do count, and base64-embedded images count fully and will blow your budget fast. Host images externally, avoid base64 in email, and keep your raw HTML under about 90KB for margin.

How do I compress images for email without losing quality?

Match the method to the format – JPEG is lossy so you can push it hard (quality 60-80 is usually the sweet spot), while PNG is lossless and benefits from color-table optimization. Always run images through a dedicated compressor after exporting from your design tool, since design-tool exports are rarely optimal and a second pass commonly cuts 20-70% with no visible loss. Watch gradients closely, since over-compression makes them band. Free tools like Squoosh and ImageOptim, or paid ones like TinyPNG and ShortPixel, all do the job well.

Do I still need alt text if my images are optimized?

Yes, more than ever. Alt text is what shows when an image is blocked – which happens by client default, corporate policy, slow connections, or the recipient never clicking “show images.” Good alt text keeps your message and call to action readable with zero images loaded; it’s also an accessibility requirement for screen-reader users and a mild positive signal for spam filters. In many clients you can even style the alt text so a blocked hero still looks on-brand. No amount of compression replaces a working fallback.

Can a non-developer optimize images for an email?

Swapping and compressing images inside an existing, well-built template – resizing to the right dimensions, running them through TinyPNG or Squoosh, keeping file sizes sane – is absolutely doable for a careful marketer or producer. Building the resilient structure underneath (the retina width attributes, the fallback colors, the bulletproof buttons, the VML for background images) really needs someone comfortable with HTML and the Outlook quirks. If that’s not on your team, this is the kind of work worth handing to a contractor who already has it in muscle memory.

The short version

Image optimization for email is three fights at once – file weight, format support, and dimensions – happening in an environment that’s hostile to a third of what works on the web. The core of it doesn’t really change: pick a format every client can render (JPEG, PNG, GIF, and leave WebP on your website), size images to their slot and go 2x for retina with explicit width attributes so Outlook behaves, compress hard but stop before the gradients band, host everything externally so you don’t trip Gmail’s 102KB clip, and back every image with a fallback color and real alt text so the email works when the images don’t.

The two things that’ll actually set your emails apart from the templated junk in everyone’s inbox are the ones the generic guides skip: understanding that Gmail’s clip is about code weight not image weight, and designing the whole thing to survive with zero images loaded. Get those right and your email holds up in Apple Mail, in Gmail, in the new Outlook, and in the Word-engine relic somebody’s still running in a basement office in 2029.

And if you want a quick read on whether the developer building your emails knows what they’re doing, ask them two things: why you shouldn’t use WebP in email yet, and whether image files count toward Gmail’s 102KB clipping limit. The answers tell you most of what you need to know.

I’ve got follow-ups coming – one going deeper on dark-mode image patterns, and one on where container queries take email layout over the next couple of years. They’ll be on the blog when they’re done. Subscribe if you want them to land in your inbox, ideally with every image rendering sharp and on the first try.