Image Compression for Email: The Complete 2026 Guide
An email full of un-optimised images doesn't get read. Slow rendering on a phone over flaky LTE pushes the recipient on to the next email before your hero paints. And there's a hard limit lurking at the email-client level: Gmail clips messages over 102 KB of HTML, breaking your tracking pixels and burying your unsubscribe link under a "View Entire Message" prompt. Image weight directly drives the experience.
The good news: sensible compression typically gets you a 40–70% file-size reduction with no visually-perceptible quality loss. The difference between a 1.2 MB hero and a 380 KB hero is invisible to the eye and dramatic to the load time. Across an 8-image campaign, that's 6–7 MB saved per recipient.
This guide walks through the right dimensions for email images, the JPEG / PNG / WebP decision, the compression settings that actually move the needle, animated GIFs, Outlook's image-rendering quirks (DPI scaling, max width, image blocking), CDN hosting strategy, and a free in-browser image compressor that runs entirely on your machine.
What you will learn: The right dimensions for email images (600–650 px display, 2x retina), choosing JPEG vs PNG vs WebP, the compression knobs that actually matter (quality, color depth, metadata), animated GIF compression and the 1 MB ceiling, Outlook quirks (DPI, max width, image blocking), CDN hosting strategy, and how to use the free MiN8T Image Compressor.
1 Why Image Size Matters in Email
An email that loads slowly on a phone over flaky LTE doesn't get read. It also gets deleted faster than emails that render cleanly. And there's a hard limit lurking at the email-client level — Gmail clips messages over 102 KB of HTML, including inlined images that get base64-encoded into the source. Your tracking pixels stop firing past that line. Your unsubscribe link gets buried under a "View Entire Message" prompt. Your campaign attribution silently breaks.
Even when images are externally hosted (the normal case), total email weight is what kills the experience: a 4 MB email full of un-optimised hero images takes 8–12 seconds to fully render on a 3G connection. The recipient is already on to the next email by the time your fold-image paints.
Sensible compression typically gets you a 40–70% file-size reduction with no visually-perceptible quality loss. That's the difference between a 1.2 MB hero and a 380 KB hero, on a single image. Across a campaign of 8 images, you're saving 6–7 MB per send. Multiplied by 50,000 recipients, you're saving 300–350 GB of bandwidth on every send — for the recipients, not for you.
What this article walks through
The right dimensions for email images, choosing between JPEG / PNG / WebP, the compression knobs that actually move the needle, animated GIFs, Outlook's image-rendering quirks (DPI, max width, dimension attributes), and a free in-browser image compressor that lets you compress up to 50 images at once without uploading them anywhere.
The cheapest performance win in email is image compression. The difference between a 1.2 MB hero and a 380 KB hero is invisible to the eye and dramatic to the load time.
2 The Right Dimensions
Most email templates render at 600–650 px wide on desktop. On mobile, that same image scales down to fit the viewport (typically 320–414 px wide). Retina displays render at 2x density, which means a 600-px-wide image can look slightly soft on retina screens unless you ship it at 1200 px wide and tell the email client to render at 600 px.
The 2x retina pattern
Export the image at 1200 px wide. Set the HTML width="600" attribute (the rendered display width). The browser/email client downsamples in the browser to use the extra pixel data for sharp retina rendering. File size goes up — usually 1.5x not 2x — but the visual quality on retina screens is meaningfully better.
Don't ship 4000-px-wide images and let the email client scale
This is the most common mistake. Designer exports a 4000 px hero from Figma or Photoshop, drops it into the email at width="100%", the email client scales it down to render at 600 px. Recipient downloads 4 MB they didn't need; you sent 8x the bandwidth required.
Always include width and height attributes
<img src="..." width="600" height="400" alt="...">. Without explicit dimension attributes, Outlook desktop will render the image at its native pixel size (so a 1200-px-wide retina image takes up half the screen). Always include them; they're load-bearing for Outlook, not optional like in modern web.
Mobile responsive images
If you need different image dimensions per device, use a media query in the <style> block to hide one image and show another. The total payload is both images, so this is only worth it for the hero shot — don't ship two versions of every image in the email.
3 JPEG vs PNG vs WebP
Three formats, three different ideal use cases.
JPEG: photos, gradients, complex artwork
Lossy compression that's optimized for natural images. Quality 80–85 is the sweet spot — below 80 you start to see compression artifacts in flat areas; above 85 the file size grows without visible improvement. Use JPEG for product photography, hero shots, lifestyle imagery, anything photographic.
PNG: logos, screenshots, anything with transparency
Lossless, preserves transparency, dramatically larger than JPEG for the same image. PNG-8 (256-color palette) is much smaller than PNG-24 (full color); use PNG-8 when you can, PNG-24 when you have transparency on a complex image. Use PNG for logos, line art, UI screenshots, anything with sharp edges and limited colors.
WebP: modern, smaller, but support is patchy
WebP achieves 25–35% smaller files than JPEG at equivalent visual quality. But not every email client supports WebP. Apple Mail, iOS Mail, Outlook 2019+ desktop, and Gmail (web + Android + iOS) all render WebP correctly. Older Outlook (2016 and earlier) and a few corporate-locked email clients don't — recipients see a broken image icon.
The fallback pattern for WebP
HTML email doesn't support <picture> element fallbacks. Your options are: ship JPEG/PNG everywhere (safe, slightly larger files), or ship WebP and accept the fallback gap (smaller files, occasional broken images). For most teams the math is: stick with JPEG for photos and PNG for graphics. WebP is the right answer for the web; for email it's still a hedge.
4 The Compression Knobs That Move the Needle
Image compressors expose a dozen settings; only three of them actually matter for email work.
1. Quality (JPEG)
The single most impactful setting. Quality 80 vs Quality 95 is roughly a 2x file-size difference for the same image. Quality 80–85 looks identical to the human eye for almost any natural image; Quality 70 starts to show artifacts in flat color regions. Default to 82.
2. Color depth (PNG)
PNG-8 (256-color palette) is 4–6x smaller than PNG-24 (16M-color). Almost every logo, icon, and UI screenshot can ship as PNG-8 without quality loss. Tools like pngquant and the in-browser compressor below auto-detect when PNG-8 is safe.
3. Metadata stripping
Camera EXIF data, Photoshop XMP data, color-profile data: all of it ships in the file by default and adds 5–30 KB per image without contributing to what the recipient sees. Strip metadata on every export. Exception: if you're embedding an sRGB color profile for color accuracy, leave that one in.
What doesn't matter for email
Progressive JPEG vs baseline JPEG (no perceptible difference, baseline is slightly smaller). Chroma subsampling (4:2:0 vs 4:4:4 — 4:2:0 is fine for almost everything). Color profile choice (sRGB is the only safe choice; everything else gets remapped or rendered wrong somewhere).
5 Animated GIFs in Email
GIF is its own compression problem. The format is older than email itself, the format is uncompressed by modern standards, and a 5-second animation can easily weigh 8–15 MB if you're not careful.
Hard ceiling: 1 MB per GIF
That's the practical ceiling that keeps email-client previews from refusing to render and keeps mobile data charges from feeling rude. 500 KB–700 KB is better.
The dimensions-and-frames-down approach
Two levers do almost all the work: smaller dimensions and fewer frames per second. A 600 px wide GIF at 10 fps is much smaller than a 600 px wide GIF at 30 fps, and visually almost identical for most marketing animations. Drop to 8–12 fps as a default. If the GIF still won't fit under 1 MB, scale dimensions down to 400 px and let the email client upscale.
Outlook desktop only renders frame 1
Outlook 2007–2019 desktop doesn't animate GIFs. It picks the first frame and renders that. Design the first frame as the meaningful "default" state of your animation — the punchline of the GIF should not be the surprise reveal at the end, because Outlook recipients will never see it.
For a deeper treatment of the animated-GIF question, see our when to use GIFs in email article. The short answer: sparingly, and with the first frame doing the load-bearing work.
6 Outlook's Image-Rendering Quirks
Outlook has been the most consistently-quirky email client for image rendering since 2007. Most of these are easy to work around once you know they exist.
Max image width: 1728 px
Outlook desktop refuses to render images wider than 1728 px (the limit comes from the Word HTML rendering engine). Above that size the image gets dropped and the recipient sees an empty rectangle. Practically: never ship an image wider than 1200 px to Outlook recipients.
DPI scaling on high-DPI displays
Windows desktop with DPI scaling (125%, 150%) will scale up images by the OS DPI, breaking your pixel-perfect dimensions. Workaround: set explicit width and height attributes on every <img>; that wins against DPI scaling.
Image blocking by default
Outlook (and Gmail desktop) blocks remote images by default; the recipient has to click "Download Images" to see them. Two implications: (1) write good alt text on every image so the email is intelligible without images; (2) keep critical content (CTAs, copy) as live HTML text, not images of text.
Background images: more conditional comments needed
CSS background-image doesn't render in Outlook; you need a VML fallback inside [if mso] conditional comments. This is the same pattern as the bulletproof button. See bulletproof email buttons for the full pattern.
7 Hosting and CDN Strategy
Where you host the images matters as much as how you compress them.
Use a CDN, not your application server
Hosting email images on your application's web server means a hot send (50,000 emails opening in the same hour) creates 50,000 simultaneous image requests against your app server. Your app server is not designed for that load profile. Use a CDN: Cloudflare, Bunny, AWS CloudFront, or your ESP's image-hosting feature.
HTTPS-only, always
HTTP-only image URLs trigger mixed-content warnings in modern email clients and frequently just don't render. Every image URL should be https://. Free Cloudflare gives you HTTPS at zero cost; there's no longer any excuse to ship HTTP image URLs in email.
Cache forever, version via URL
Set Cache-Control headers to max-age=31536000, immutable (one year, never revalidate). When you need to update an image, change the URL (add a hash or version query param) rather than overwriting the file. This makes opens cheaper for repeat-recipients and avoids stale-cache glitches.
Embedded vs linked: link, almost always
You can embed images directly into the email source as base64-encoded data URIs. Don't. It blows up the HTML payload past Gmail's 102 KB clip limit, balloons the SMTP message size, and inflates per-recipient bandwidth (vs the CDN model where the image is downloaded once per recipient and served from cache thereafter). Linked images, hosted on a CDN, win on every metric except the rare offline-archive use case.
Keep alt text good
Image-blocked recipients (Outlook, Gmail desktop, accessibility users on screen readers) see only the alt text. Treat alt text as a copywriting deliverable, not a checkbox — describe what the image conveys, not "image" or "logo." For decorative-only images, use alt="" (empty alt) so screen readers skip them rather than reading "image."
The free in-browser compressor
The MiN8T Image Compressor handles all of this in the browser without uploading anything. Drop in up to 50 images, pick JPEG/PNG/WebP, set quality, and export — everything runs locally via WASM-compiled libjpeg-turbo and pngquant. Free, no signup, no upload, no rate limits.
Image Optimization Built In
MiN8T's editor optimizes uploaded images automatically — resize to 2x display, compress to ~80% quality, strip metadata, and serve from the CDN. Drop in a 4 MB hero from Figma; the recipient gets a 380 KB hero. No tooling, no hand-tuning.
Start Building for Free
