Email is the one place where modern formats do not help you and images are blocked by default. Both facts should change how you prepare them.
For a 600-pixel email body, export at 1200 pixels and set the HTML width to 600. That covers high-density screens, which is most phones, where email is mostly read.
WebP is not reliably rendered across email clients, and a broken image in an email is far worse than a slightly larger one. Photographs go in JPEG, flat graphics and logos in PNG.
Aim under 100 KB per image and about 1 MB across the whole email. Readers on mobile data notice, and some clients handle heavy messages badly.
Many clients block images until the reader chooses to load them, so alt text is frequently the only thing they see at first. Style it if your platform allows — legible fallback text is a genuine design element in email.
An all-image email shows as a blank rectangle with images off, and is more likely to be filtered as spam. Keep the important message in real text.
Email clients are not browsers. Outlook on Windows renders HTML using the Word engine, several clients strip CSS aggressively, and support for anything modern is inconsistent and slow to change.
The practical consequence for images: use JPEG and PNG, avoid WebP and AVIF, keep the markup simple, and test in the clients your list actually uses rather than assuming. The 25–35% WebP would save is not worth a broken image for a portion of your readers.
A significant share of readers see your email with images suppressed until they act. That reframes the whole design: your images are the enhancement, not the message.
Three consequences. Alt text is content, not an accessibility checkbox — it may be the only version of the image anyone reads. Text-on-image is a bad idea, since blocked images take the words with them. And an email that is one large image conveys nothing at all in that state.
Gmail truncates messages above roughly 102 KB of HTML and shows a "view entire message" link, which hides your footer and unsubscribe link and breaks open tracking.
This is measured on the markup, not the images — a 500 KB photograph does not contribute to it. What does is bloated inline CSS, repeated table markup and long tracking URLs. Keeping the HTML lean is a separate discipline from keeping the images small, and they get confused constantly.
Embedded images inflate every copy of the message, count against attachment limits, and trigger spam heuristics. Host them and reference them by URL, which every email platform does by default.
Use a stable, fast host with long cache headers, and never change or delete a URL after a send — some readers open a newsletter months later, and a broken image in an archived email is permanent.
Many clients now invert or adjust colours in dark mode, and logos with a white background become white boxes floating in a dark layout.
Use transparent PNGs for logos and marks so they sit on whatever background the client renders, and check a send in dark mode before it goes out. It is the most common visual fault in modern email and it is easy to avoid.
These run in your browser on any device, so nothing is uploaded and there is nothing to install.
By pixels or percentage, aspect ratio locked, across a whole batch.
Open the toolWhere a photograph stops being a compromise.
Open the toolLossless by default, with transparency carried through untouched.
Open the toolOne setting across a whole folder, processed in parallel, downloaded as a ZIP.
Open the toolQuestions
Every answer below is present in the page source, expanded, so it can be read without opening anything.
Export at 1200 pixels wide and display at 600, which is the standard email body width and covers high-density screens. Aim for under 100 KB per image and about 1 MB across the whole message.
Not reliably. Support across email clients is inconsistent, and a broken image is far worse than a slightly larger one. Stay with JPEG for photographs and PNG for graphics.
Because the HTML exceeds roughly 102 KB. That is markup size, not image size — a large photograph does not contribute. Look at inline CSS, repeated table markup and long tracking URLs instead.
Link to hosted images. Embedding inflates every copy of the message, counts against attachment limits and increases the chance of being filtered as spam.
Because it is a JPEG or an opaque PNG with a white background, and the client has darkened everything around it. Use a transparent PNG so the logo sits on whatever background the client renders.
More than anywhere else. Many clients block images by default, so alt text is frequently the only version of the image a reader sees. Treat it as content, and never put your key message inside an image.
From the blog
More background from the blog.
Attachments are base64-encoded in transit, which inflates them by about a third. A 20 MB limit is really a 15 MB limit. Resize to 1600 pixels on the long edge and encode at quality 80, and a photograph lands near 150 KB.
9 min read
Resize before you compress. Measured on one photograph: half the width at quality 80 produced a 16.4 KB file, while full width at quality 40 produced 20.6 KB and looked far worse. The order of operations matters more than the settings.
8 min read
PNG stored the same photograph in 1274.1 KB where JPEG needed 67.5 KB — nineteen times larger. On a flat graphic PNG won. On a smooth gradient PNG lost to JPEG by a factor of two, which surprises most people.
9 min read