Image optimizer

Why image weight matters in an email

Gmail clips a message whose HTML is larger than about 102 KB. That limit is about the HTML source only. Images are separate files, fetched after the message opens, so a 900 KB hero does not clip anything. It does something worse: it decides how long the email looks broken.

A large share of marketing email is opened on a phone, often on mobile data. The text arrives first and the images load after it. A light hero is there before the reader has finished the subject line. A heavy one paints in slowly, or sits as an empty box with its alt text while the reader scrolls past the offer. Nothing is technically wrong, and the email still reads as broken.

The usual cause is the export. The hero leaves the design file at the design's size, often four times the pixels the email shows, in whatever format the design tool picked. The fix is always the same: resize it to the width the email shows it at, doubled for retina screens, in a format every inbox shows.

The retina rule: export at 2x, set the width in the HTML

Phones and most laptops draw two device pixels for every CSS pixel. An image shown at 600 px needs a file 1,200 px wide to look sharp. The common case is the full-width hero in a 600 px email: export it at 1,200 px and put width="600" on the img tag. A 300 px product tile needs a 600 px file.

The width attribute is not optional. Outlook on Windows ignores CSS widths on images and shows the file at its own pixel size, so a 1,200 px hero without width="600" spills out of the email at twice its size. Set the attribute in pixels, and add max-width:100% and height:auto in the style for phones.

The optimizer applies the rule for you. Set the width each image is shown at and it makes the file twice that wide. If you do not say, it guesses: a file 960 px or wider is taken as a full 640 px column, one between 640 and 960 px as a 2x export of half its width, and a smaller one as shown at its own size. It never upscales, because added pixels add weight and no sharpness. Going past 2x buys nothing either: a file more than three times its shown width is pure weight.

JPEG, PNG, GIF, WebP: what inboxes show

• JPEG is for photographs. A photo compresses far smaller as a JPEG than as a PNG, and every email client shows it.
• PNG is for transparency and flat artwork: a logo, an icon, a badge. Every client shows it. A PNG of a photograph is the most common reason a hero is three times heavier than it needs to be.
• GIF shows everywhere, animation does not. Outlook 2007 to 2019 on Windows shows only the first frame, so that frame has to carry the message on its own.
• WebP and AVIF are smaller at the same quality, and support is partial. Apple Mail and Gmail show WebP; Outlook on Windows shows a broken image, and some webmail does too. AVIF is shown by fewer clients still. An img tag has no fallback every inbox honours.
• SVG is not shown by most email clients. Use a PNG at 2x.

So the optimizer only writes JPEG or PNG. It samples each image's pixels: transparency keeps it a PNG, and so does flat artwork with 64 colours or fewer. Everything else becomes a JPEG at quality 82 by default, adjustable from 50 to 95. It takes PNG, JPEG, GIF and WebP in, so a WebP export comes back as something every inbox shows. Animated GIFs are left alone, because a browser cannot re-encode their frames.

How heavy is too heavy: per image and per email

SendLint's guideline for one image is 200 KB. It is the default of the Image File Size check in a full analysis, and a client's Brand Rules can set a different maximum. Image check, the standalone checker, applies these lines:

• Over 200 KB: flagged to improve. Over 1 MB: a problem to fix, heavy enough to hold up the whole email on a phone connection.
• A PNG over 100 KB with no transparency: as a JPEG it would be a fraction of the weight.
• A file narrower than its shown width: stretched and blurry. Between 1x and 1.5x: sharp on ordinary screens, soft on retina ones.
• A 1x1 open-tracking pixel is marked fine, and a full analysis never requests it, because each request through a sending platform is recorded as an open.

For the whole email, the checker reports the total image weight across every image it could size, and how many it could not. It does not fail an email on the total, because a twelve-tile product grid and a one-hero announcement are not comparable. Read the total next to the heaviest files: when one image is most of it, that image is the fix. If your team works to a total budget, that line is the number to hold it against.

The optimizer shows the size before and after, per image and for the set. When a new file is still over 200 KB it says so: show it narrower, or lower the quality. When the result is not at least 3% smaller, it tells you to keep the original.

Background images and Outlook on Windows

Outlook on Windows does not show CSS background images. A background there needs a VML fallback inside a conditional comment, and on anything other than a table cell it vanishes without one. Gmail and Apple Mail show CSS backgrounds, but a reader with images off sees none of them.

• Set a background colour close to the image's average tone, so the text on top stays readable when the image does not load.
• Keep the copy in live text over the image, never baked into it.
• Size a background image like any other: twice the width of the box it fills, JPEG for a photo.

Alt text for every image, empty for decoration

Every img tag needs an alt attribute. Without one, a screen reader announces the file name and an inbox with images blocked shows an empty box. An image that carries meaning gets a short description: "Family unpacking groceries in a sunlit kitchen." A logo gets its name: "Harbourline logo." A banner with words in it gets those words. A spacer, a divider, or a picture that only repeats the copy beside it gets alt="", which tells a screen reader to skip it. Swapping an optimized file into the build is a good moment to check it.

Write it with the Alt text writer and email accessibility checklist.

Your images never leave your browser

This optimizer is free, needs no account, and runs entirely in your browser. Each image is read, resized and encoded on your own machine, and nothing is uploaded to SendLint or anywhere else. That matters for images still under embargo: a launch hero, a price, a product not yet announced. Download the files one at a time or all as a .zip, and swap them into the build.

From one image to every image in the campaign

The optimizer works on files you already have. Image check works on the email as built: paste the HTML or drop the .eml from a test send, and it downloads every image once and reports size, format, pixel size against shown size, and alt text, worst first.

In a SendLint campaign the same image checks run on every email, in every round, for every version and language, next to the checks against the approved assets: the copy deck, the links and alt text, and the approved design. A hero that comes back at 845 KB in round two is a finding with the file and its size, and it stays open until a round where it is fixed. The Harbourline sample campaign on the demo shows a full run.

Related: Image check, the email QA checklist and the SendLint demo.

Frequently asked questions

Do I need an account?

No. This one runs entirely in your browser — the images are read, resized and encoded on your machine and never uploaded.

Why not WebP?

Outlook on Windows shows a broken image for WebP, and email has no way to offer a fallback. JPEG and PNG show everywhere.

What about animated GIFs?

They are read and reported but left as they are: a browser can't re-encode a GIF's frames. Optimize those in a GIF tool.