Updated: July 18, 2026
To compress images for email newsletters, resize each image to the width at which it will actually be displayed, choose JPEG for most photos or PNG when transparency or sharp graphic edges matter, then reduce the file size until the image looks clean at its display size. Treat 200 KB for a hero image and 100 KB for inline images as practical starting targets, not platform-enforced limits. Keep two budgets separate: the HTML payload (markup, inline CSS, repeated code) determines whether Gmail clips your message at approximately 102 KB; the image download size (each remotely hosted file) determines how quickly images load for recipients. Compressing images and reducing HTML size solve different problems and both matter.
Key Takeaways
- Keep each image file well under 1 MB—practical starting targets are under 200 KB for hero banners and under 100 KB for inline images. These are starting points, not Gmail or ESP hard limits.
- Resize to the width at which the image will be displayed before compressing. A 4000 px photo constrained by HTML to 600 px still forces recipients to download the full file.
- Use JPEG for photographs, PNG for graphics, logos, or anything requiring transparency, and WebP only after verifying your audience's client support.
- Gmail's approximately 102 KB clipping threshold applies to the HTML source size, not to remotely hosted image file sizes. Clean up markup and inline CSS to reduce HTML; compress images to reduce download time.
- Always include alt text and set width and height attributes in your HTML. Test in Gmail, Outlook, and Apple Mail before sending.
What Image Compression Changes—and What It Does Not
Image compression reduces the download size of each image file. When images are hosted remotely and linked by URL in your email, that download happens on the recipient's device after the email is opened—it is separate from the email's HTML payload.
What image compression improves:
- Loading speed. Smaller files render faster, especially on mobile networks.
- Rendering reliability. Oversized images can break column layouts in clients such as classic Windows Outlook (which uses Word's rendering engine and handles CSS differently from browsers).
- Data cost for recipients. Smaller files use less mobile data.
What image compression does not directly control:
- Gmail HTML clipping. That threshold is approximately 102 KB of HTML source—markup, inline CSS, tracking parameters, and repeated code. Remotely hosted images do not count toward this number. To reduce clipping risk, simplify your template's HTML.
- Inbox placement / deliverability. Sender reputation, authentication (SPF, DKIM, DMARC), complaint rates, list quality, and content signals are the primary factors. Faster-loading images improve the reader experience but are not a deliverability lever on their own.
HTML Size vs Image Size: Two Different Email Budgets
| Budget | What it includes | Primary risk | How to reduce |
|---|---|---|---|
| HTML/source size | Markup, inline CSS, repeated code, tracking parameters | Gmail clips at approximately 102 KB | Simplify template, reduce inline styles, remove redundant code |
| Image download size | Remotely hosted JPEG, PNG, GIF, WebP files | Slow loading, high data use | Resize to display width, compress file size |
| Embedded images (base64) | Images encoded inline in the HTML | Increases HTML size directly | Avoid; use remote hosting instead |
Practical Starting Sizes for Newsletter Images
The values below are commonly used editorial targets based on typical email template widths. They are not enforced limits imposed by Gmail, Outlook, or any ESP—your actual targets should reflect your template, visual quality needs, and the results of send tests.
| Image type | Suggested rendered width | Starting file-size target | Suggested format |
|---|---|---|---|
| Hero / header banner | 600 px | under 200 KB | JPEG or WebP (if client-tested) |
| Inline content image | 300–500 px | under 100 KB | JPEG |
| Product image | 400–600 px | under 150 KB | JPEG |
| Logo | 200–400 px wide | under 50 KB | PNG (transparent) |
| CTA button (image-based) | 300 px wide | under 30 KB | PNG |
| Animated GIF | 600 px | under 1 MB | GIF — use sparingly |
On high-DPI (Retina) screens: Exporting a source image at approximately 2× the rendered display width—for example, a 1200 px source displayed at 600 px—improves sharpness on high-density screens. Because this roughly doubles file size, apply it selectively and check that the result stays within your file-size targets. For many newsletters, 1× source at careful compression is an acceptable trade-off.
The 4-Step Compression Workflow
Step 1: Resize to the Display Width
Start with dimensions, not bytes. Exporting a 4000×3000 photograph and then constraining it with width="600" in your HTML forces every recipient to download the entire original file.
- Open the image in your editor (Preview on macOS, Photoshop, Figma, GIMP, or a browser-based tool).
- Set the canvas or export width to the rendered display width—for example, 600 px for a header. If targeting high-DPI screens, export at approximately 1200 px and confirm the file size remains acceptable.
- Lock the aspect ratio to avoid distortion.
Step 2: Choose a Format Your Audience's Email Clients Support
| Format | Use it for | Compatibility notes |
|---|---|---|
| JPEG | Photographs, gradients, complex images | Broadly supported; lossy—text and sharp edges can show artifacts at low quality |
| PNG | Logos, screenshots, text-heavy graphics, transparency | Broader file sizes than JPEG for photos; well-supported |
| WebP | Smaller files where client support is confirmed | Support varies by client version; classic Windows Outlook has limited support—check a current compatibility reference before using |
| GIF | Light animation | Classic Windows Outlook (Word renderer) typically shows only the first frame; design first frame to stand alone |
| SVG | — | Avoid in email; many clients block or strip SVG |
For most newsletters, default to JPEG for photos and PNG for graphics. Only adopt WebP after testing against your subscriber base's actual client mix using a current compatibility resource such as Can I Email (caniemail.com).
Step 3: Reduce the File Size
Once dimensions and format are set, bring the bytes down:
- JPEG quality: A quality setting in the 60–75 range in many editors produces files that are meaningfully smaller than quality 90+ while remaining visually clean. Note that quality scales are not standardized across encoders—start in the middle, compare the output visually at display size, and adjust.
- Strip metadata: Camera EXIF data (location, device info, timestamps) adds bytes with no visual value. Most export workflows strip it automatically; confirm this in your tool's settings.
- PNG color depth: For simple graphics without gradients, reducing from 24-bit to 8-bit color can shrink the file. Check for color banding or transparency issues before using the reduced file.
A browser-based compressor such as LessMB can be used to reduce image file size before adding the image to your newsletter. After compression, verify the result at the actual display size to confirm no visible quality loss.
Practical file-size targets to work toward (starting points, not platform limits):
- Hero / header image: under 200 KB
- Inline content image: under 100 KB
- Logo: under 50 KB
Step 4: Verify Before You Send
Compression is not done until you have confirmed the result renders correctly and measured your actual sizes.
Check image quality:
- View the compressed image at 100% and at the intended display size. Look for blocking artifacts, color banding, blurred text, or washed-out edges.
- Confirm that alt text is readable in your email template with images disabled.
Measure sizes:
- Note the original file size and the compressed file size, and calculate the reduction. A 70–85% reduction from a typical camera original is common.
- In your ESP's code view or a preview tool, check the total HTML source size. If it approaches 102 KB, reduce markup—not necessarily images—because the HTML size and image download size are separate budgets.
Send test emails:
- Gmail (web and mobile): Look for a "Message clipped" notice at the bottom. If present, reduce HTML size.
- Classic Windows Outlook (desktop): Confirm layout holds. Background images and GIF animation have inconsistent support in the Word rendering engine used by classic Windows Outlook versions.
- Apple Mail on iOS: Check image sharpness at display size.
- Confirm that images load correctly with images blocked, and that alt text communicates the message.
Image Optimization Checklist
- Image resized to display width (not relying on the client to scale a larger file)
- Format chosen to match the content type and confirmed client support
- File size within target (hero under 200 KB, inline under 100 KB — adjust to your template)
- HTML source size checked separately; under approximately 102 KB if Gmail clipping is a concern
- Alt text written for every image
-
widthandheightattributes set in the HTMLimgtag - Compressed image checked visually for artifacts, color banding, or blurred text
- Tested in Gmail, Outlook, and Apple Mail before sending
- No critical content placed only in background images (support is inconsistent in some Outlook versions)
- Animated GIFs, if used, have a first frame that stands alone; file under 1 MB
Common Mistakes That Break Newsletters
Relying on the client to scale images. Sending a 3000 px image and constraining it with width="600" in HTML still forces every recipient to download the full original. Resize before exporting.
Confusing image size with HTML size. Recipients who see "Message clipped" in Gmail need the email's HTML reduced—removing duplicate code, unused inline styles, or long tracking parameters—not necessarily smaller image files. The two budgets are separate.
Using background images for key content. CSS background images have inconsistent support in some Outlook client versions, particularly classic Windows Outlook. If essential content (such as a headline or primary call to action) relies on a background image, it may not appear for a portion of your audience.
Skipping alt text. Many recipients have images blocked by default, and some email clients do not load images automatically. Alt text conveys the message when the image does not render—it is also an important accessibility best practice.
Omitting width and height attributes. Without explicit dimensions, the email layout may reflow as images load. Setting width and height on each img element helps maintain layout stability across clients.
Overusing animated GIFs. Large GIFs substantially increase download time. In classic Windows Outlook (Word renderer), only the first frame is typically displayed. Keep animation minimal, keep the file size low, and design the first frame to work independently.
Using image-based CTA buttons by default. HTML live-text buttons are generally more accessible and render reliably when images are blocked. Use image-based CTAs only when design requirements make them necessary, and always provide meaningful alt text.
Tools for Compressing Newsletter Images
| Tool | Type | Notes |
|---|---|---|
| LessMB | Browser-based | Image compression in the browser without installation |
| TinyPNG / TinyJPG | Browser-based | JPEG and PNG compression |
| Squoosh (squoosh.app) | Browser-based | Side-by-side format and quality comparison |
| ImageOptim | macOS app | Drag-and-drop batch optimization |
| Photoshop — Export As | Desktop | Precise dimension and quality control with live preview |
| Sharp / ImageMagick | CLI | Automated compression for recurring or high-volume sends |
Verify each tool's current supported formats and options on its official product page, as capabilities can change over time.
Next Steps
- Audit your last send. Open the HTML source in your ESP and check the total source size. Note the file size of each image. Identify whether any clipping or slow-loading issues are driven by HTML bloat or by image file size—the fix differs for each.
- Add compression to your pre-send checklist. The workflow is: resize to display width → choose format → compress → verify quality → test in clients → check HTML size.
- Pick one tool and standardize. Consistent tooling means images leave your workflow already optimized. A browser-based option such as LessMB requires no installation and works on any machine; desktop tools like ImageOptim or command-line tools like Sharp suit higher-volume or automated pipelines.
- Re-test after any template changes. Layout edits often introduce additional inline CSS or markup that can push HTML size higher. Re-check after significant template updates.
FAQ
What is the best image size for email newsletters?
A practical starting point is 600 px wide for a hero or header banner, and 300–500 px wide for inline content images. These are useful defaults based on common template widths, not platform-enforced limits. Your actual targets should reflect your specific template, audience device mix, and visual quality requirements.
Does Gmail clip emails over a certain size?
Gmail commonly clips messages when the email's HTML source size reaches approximately 102 KB, replacing the truncated content with a "View entire message" link. This threshold applies to the HTML payload—markup, inline CSS, repeated code, and tracking parameters. It does not apply to the download size of remotely hosted images. To reduce clipping risk, simplify your HTML template rather than focusing only on image compression.
Do remotely hosted images count toward Gmail's 102 KB clipping threshold?
No. When images are hosted on a remote server and referenced by URL in the email, they are downloaded by the recipient's client separately and do not count toward the HTML payload size. Only images encoded as base64 data URIs and embedded directly in the HTML add to the source size—which is one reason inline embedding of large images is generally avoided.
Which image format is best for email newsletters?
JPEG works well for photographs and complex images with gradients. PNG is preferable for logos, screenshots, and graphics requiring transparency or sharp edges. WebP produces smaller files but has variable support across email clients—verify your audience's client mix using a current compatibility resource before adopting it. SVG should be avoided in email, as many clients block or strip it.
Should I use an animated GIF in my newsletter?
Use animated GIFs sparingly. They increase download size quickly, and classic Windows Outlook (which uses Word's rendering engine) typically displays only the first frame rather than animating the GIF. Design the first frame to communicate the message independently, keep the file under 1 MB, and confirm the animation adds value before including it.
How do I check if Gmail clipped my email?
Send a test to a Gmail account and look for the "Message clipped" text at the bottom of the message. If it appears, check the HTML source size of your email in your ESP's code view—not the image file sizes—and reduce markup, inline styles, or repeated code to bring the HTML payload below approximately 102 KB.
Does compressing newsletter images improve deliverability?
Image compression improves loading speed and rendering reliability, which benefits the reader experience. Deliverability—whether your email reaches the inbox—is primarily determined by sender reputation, authentication records (SPF, DKIM, DMARC), complaint rates, list quality, and content signals. Faster-loading images are good for subscribers but do not directly guarantee inbox placement.
Should Retina email images be twice the displayed width?
Exporting a source image at approximately 2× the rendered display width—for example, a 1200 px source for a 600 px display width—can improve sharpness on high-DPI screens. Because this roughly doubles file size, weigh the quality gain against the extra download time and adjust your compression settings accordingly. For many newsletters, a carefully compressed 1× source is an acceptable trade-off.