Easily compress and resize your images to fit email attachment limits without losing quality.
Run through this list every time. It takes fifteen seconds and eliminates the most common email image failures.
1. Total attachment size. Add up every file you're attaching. If the total exceeds 80% of your provider's limit, remove or compress something. Gmail gives you 25MB, but that includes encoding overhead — base64 encoding adds roughly 33% to file size, so your actual usable space is closer to 18MB.
2. Individual file size. Even if the total fits, a single 12MB image will take your recipient thirty seconds to download on a mobile connection. Keep individual images under 1MB for inline use, under 2MB for attachments.
3. Image dimensions. An email body is typically 600-650px wide. Sending a 3000px-wide image means the client either scales it down (losing control of how it looks) or displays it at full size (breaking the layout). Resize to 600px for inline images.
4. Format match. Photographs → JPEG. Screenshots → PNG. Graphics with fewer than 256 colors → PNG-8. Animated images → GIF (but keep file size under 500KB). Transparent backgrounds → PNG. Using the wrong format wastes kilobytes for no visual benefit.
5. Color space. Most monitors display sRGB. Images in Adobe RGB or ProPhoto RGB will appear desaturated or shifted in most email clients. Convert to sRGB before attaching.
6. Filename. "IMG_20240315_142233.jpg" communicates nothing. Rename to something your recipient understands: "invoice-march-2024.jpg" or "product-shipping-box.png".
The numbers below reflect what delivers reliably, not theoretical maximums. These targets account for base64 encoding overhead, mobile downloading, and the reality that your recipient might be on airplane Wi-Fi.
Inline images (visible in the email body): 100-500KB at 600px wide. This range loads instantly even on 3G connections and doesn't trigger any email client's image-blocking behavior. Gmail displays these without requiring the recipient to click "load images."
Standard attachments: 500KB-1.5MB at 1200px wide. Suitable for product photos, event screenshots, or documents where detail matters. The recipient downloads these manually, so the slightly larger size is acceptable.
Photo-quality attachments: 1.5MB-3MB at full resolution (capped at 3000px on the longest side). Use only when the recipient explicitly needs high-resolution output — a photographer reviewing proofs, a print shop receiving files, or a client approving artwork. Always mention the file size in your email body: "I've attached three high-res photos, about 2MB each."
Above 3MB per image: Don't attach it. Use a cloud link instead. Google Drive, Dropbox, and OneDrive all offer free sharing. Attaching a 5MB image forces your recipient to wait for a download they might not want. A link lets them choose when and whether to download.
Screenshots deserve special attention because they're the most commonly shared image type in professional email, yet they're routinely the worst-optimized.
A 1920×1080 screenshot on a Retina/HiDPI display is actually captured at 3840×2160 pixels. That's 8.3 million pixels. Saved as an uncompressed PNG (which many screenshot tools do by default), it weighs 8-12MB. The same screenshot, resized to 600px wide and saved as PNG-24, weighs 80-150KB. Same information, 99% smaller file.
The compression math changes for screenshots versus photographs because screenshots contain large flat-color areas, sharp text edges, and minimal color variation. JPEG's lossy compression actually harms screenshots — it creates ringing artifacts around text and blurs the thin lines in UI elements. PNG's lossless compression handles these patterns perfectly.
If you share screenshots by email, adopt this workflow: capture → resize to 600px wide → save as PNG → attach. Tools like Pixes email optimizer automate this in one step, detecting screenshot content and choosing the right format automatically.
Optimizing images for email isn't purely a technical exercise. The experience your recipient has determines whether your message gets read, ignored, or marked as annoying.
On mobile (60%+ of email opens): A 2MB attachment requires a deliberate tap to download on most mobile email clients. On cellular data, that's a 3-5 second wait. If your image is purely decorative — a banner, a decorative divider, a stock photo — your recipient will resent the download. Reserve attachments for images the recipient actually needs to see.
In corporate environments: Many companies run email through security appliances that scan attachments. Large images slow down delivery by seconds to minutes. Some corporate firewalls strip attachments above a threshold without telling the sender. If you're emailing a client at a large enterprise, keep attachments small and mention them in the email body so the recipient can alert IT if they don't arrive.
For accessibility: Email clients that block images by default (Outlook, many corporate configurations) will show your alt text instead. Write descriptive alt text: "Q3 revenue chart showing 15% growth" — not "image" or "chart". If your image is decorative, empty alt text (alt="") signals screen readers to skip it.
Across email clients: Outlook 2016+ downscales images wider than 1000px to a low-resolution rendering. Apple Mail renders at full resolution. Gmail compresses your images server-side if they're displayed inline. You can't control the recipient's client, but you can control what you send — keep inline images at 600px so no client needs to modify them.
Some images shouldn't be emailed at all, regardless of how well you compress them.
Sharing with multiple people: Don't attach the same photo to five separate emails. Upload it once, share a link. Every duplicate attachment consumes storage on both the sender's and recipient's mail server. A single cloud link serves the same purpose at zero storage cost.
Images that will change: If you're sharing a work-in-progress design, a draft screenshot, or a document that will be revised, attach a link to the live file rather than a static image. A Dropbox or Google Drive link always points to the current version. An attached image is frozen in time.
Large image collections: Sending twenty product photos by email is inconsiderate even if each file is small. The recipient's inbox wasn't designed for 40MB of attachments in a single thread. Create a shared folder and send one link.
Sensitive images: Email is not secure. Attachments pass through multiple servers and can be cached at various points. If you're sending medical images, legal documents with embedded images, or anything with personal data, use an encrypted file-sharing service with access controls and expiration dates.
The decision tree is simple: one image to one person for immediate viewing → optimize and attach. Anything else → use a link.
Every article about image formats says the same things. Here's what specifically matters when your image is going into an email.
JPEG (quality 70-85%): Best for photographs sent as attachments. At quality 80%, a 600px photo weighs 60-120KB. The compression artifacts are invisible at email viewing sizes. Avoid JPEG for images with text — the compression blurs letterforms.
PNG-24: Best for screenshots and graphics with text. No compression artifacts, but file sizes are 2-5× larger than JPEG for photographs. A 600px screenshot at PNG-24 is typically 100-250KB — perfectly reasonable for email.
PNG-8: Useful for simple graphics with fewer than 256 colors — charts, diagrams, icons, logos. A 600px logo saved as PNG-8 might weigh only 15-30KB. Same image as PNG-24 would be 80KB.
GIF: Only for animations. Maximum 256 colors makes it poor for photographs. An animated GIF under 500KB can work in email, but many corporate email clients block animated content or only show the first frame. Test with your specific recipients before relying on GIF animations in email.
WebP: Not universally supported in email clients. Outlook 2016 and older don't render WebP. Apple Mail supports it. Gmail renders it in the web interface but not in all mobile apps. Until 2026, stick with JPEG and PNG for email to guarantee compatibility.