How to Reduce Image File Size for Email

Why Email Images Are Different

Email is not the web. While modern browsers support WebP, advanced CSS, and responsive images, email clients are a decade behind. Outlook still uses Microsoft Word's rendering engine for HTML emails. Gmail strips most CSS. Apple Mail is comparatively modern but still has quirks. This means the rules for images in email are different from — and stricter than — the rules for images on websites.

Format Rules for Email

Use JPEG for photographs and PNG for graphics with transparency. That is the entire list. WebP is not reliably supported across email clients — Gmail on desktop supports it, but Outlook, Yahoo Mail, and many mobile clients do not. For the full format comparison, see JPEG vs PNG vs WebP. AVIF support is even worse. Stick with JPEG and PNG for maximum compatibility.

GIF is supported for animations, but animated GIFs are heavy and many email clients (particularly Outlook) will only display the first frame. Use them sparingly.

Size Limits and Constraints

Most email services impose total message size limits. Gmail caps messages at 25 MB, but in practice, emails over 10 MB are likely to be clipped or land in spam. Outlook limits individual attachments to 20 MB but embedded images contribute to the total message size. A good rule of thumb is to keep the total weight of all images in an email under 1 MB, with individual images under 200 KB.

For email campaigns, most email service providers recommend keeping the total email size under 100 KB (including HTML) for optimal deliverability. This means each image should be as small as possible — 20-50 KB is a good target for most email images.

Recommended Dimensions

Standard email content width is 600 pixels. Some modern templates stretch to 640 or 660 pixels, but 600 is the safe maximum. For retina displays, create images at 1200 pixels wide and display them at 600 pixels using HTML width attributes — this gives sharp images on high-DPI screens without breaking the layout on older clients.

For hero banners, 1200 x 600 pixels (displayed at 600 x 300) is a common standard. For product images, 600 x 600 pixels is reliable. For icons and small graphics, 100-200 pixels wide is sufficient.

Compression Settings

For JPEG images in email, compress at 70-80% quality. Email images are typically viewed at small sizes on screens, so aggressive compression is less noticeable than it would be on a full-screen website image. A MozJPEG-encoded image at 75% quality will look excellent at email sizes while keeping file sizes small. The mechanics of why MozJPEG produces smaller files at the same quality are explained in MozJPEG vs Standard JPEG.

For PNG images, use a tool that applies proper PNG optimization (like pngquant) to reduce the color palette. A 256-color PNG is often visually indistinguishable from a full-color PNG for logos and simple graphics, at a fraction of the file size.

Practical Workflow

Resize your images to the correct dimensions first, then compress. Never send a 3000px wide photograph and rely on HTML to scale it down — the email client will still download the full file. Resize to 1200px wide maximum, compress with JPEG at 75% quality, and verify the file size is under 100 KB. For most email images, this workflow will produce excellent results.

A Worked Example: A 5-Image Newsletter

Suppose your weekly newsletter has a 600×300 hero, four 300×300 product thumbnails, and a small 200×60 logo. Here is what each one should weigh:

• Hero (600×300, MozJPEG q=75): target 40 KB. Holds detail at email viewing distance without exceeding deliverability limits.
• Each product thumbnail (300×300, MozJPEG q=75): target 15 KB. Four of them = 60 KB.
• Logo (200×60, PNG with reduced palette): target 4 KB. PNG because the logo has flat colors and a transparent background.

Total image weight: ~104 KB. Add ~30 KB of HTML and CSS, and the entire newsletter lands well under the 200 KB threshold that email service providers like Mailchimp and Klaviyo recommend for best deliverability. A newsletter at this size loads near-instantly even on slow mobile networks.

Common Misunderstandings

• Adding `width="600"` in HTML does not shrink the file the recipient downloads. The full image bytes still travel down the wire. Resize the source first.
• Embedding images via `<img src="data:image/jpeg;base64,...">` does not help. Base64 inflates the size by ~33% and breaks caching. Always link to a hosted image URL instead.
• Animated GIFs are usually a bad idea in email. Outlook only displays the first frame, so design the first frame to convey the message on its own, or use a static image.

Frequently Asked Questions

Q: Why does my email client strip my images?

Most email clients require the recipient to click "load images" before remote content downloads — this is an anti-tracking measure. There is no fix; design your email so the text alone carries the message, with images as enhancement.

Q: Should I host email images on my CDN or use the email service provider's image hosting?

Use the ESP's hosting if your provider offers it (Mailchimp, Sendgrid, Klaviyo all do). Their CDN endpoints are pre-warmed and trusted by spam filters. Self-hosted images can occasionally trip "this email contains images from an unfamiliar source" warnings, especially in Outlook.

Q: Can I send WebP at all?

Apple Mail, Gmail (web), and most modern clients render WebP fine. Outlook desktop and several mobile clients do not. For predictable rendering across the long tail, JPEG and PNG are still the only safe formats in 2026. See the format comparison for the full breakdown.