filehugger.comThe exact steps
- Decode the picture
- Resize to ≤ 1920 px (longest side)
- Encode as WebP at 80%
One WebP per picture, ready to upload; grab the batch as a ZIP on the download page.
Why this chain
WebP was smaller than JPEG on every content type we measured — 31% on a photo, 57% on a flat illustration — and unlike JPEG it keeps transparency. Capping the long side at 1920 px matters more than the quality slider: screens rarely show more, and the resize is where the bulk of the saving comes from.
Doing it without the recipe
Nothing here is hidden behind the chain — the same three operations are on their own pages, and doing it by hand is two or three passes: Resize Image to cap the long side, then Image to WebP to convert, or Compress Image if you want to sit on the quality slider and watch the file size move. The recipe exists because that is three uploads and three downloads per batch, and because the order matters: resizing before encoding is what produces the saving, and doing it the other way round throws away quality twice.
When this chain is the right one
Reach for this when you have a folder of mixed formats — a few PNG screenshots, some JPEGs from a camera, a stray HEIC someone sent from a phone — and they all need to become the same thing before they go near a site. It is the wrong tool for a single hero image you care about, where you want to see each quality step and decide; use the individual compressor for that and keep the slider in your own hands.
Honest limits
Very old browsers and some legacy CMSes still reject WebP — if the destination is one of those, use the plain JPG converters instead. Transparency is preserved; animated inputs contribute their first frame only.