WebP compression — Delivery workflow

Worked example

To deliver WebP files, confirm the destination accepts the format, keep a JPG or PNG fallback and name the set clearly.

A blogger publishing banners at 1600 × 900 can use the WebP on a page and keep the original as a fallback. Web pages and many content systems read WebP, but email clients and some print or marketplace uploads do not. Check the destination upload guide before you replace a working JPG, and test a single file first.

The download is named after the source plus compress and ends in .webp, such as banner-compress.webp. Add the size or purpose, for example banner-1600.webp, so a teammate can tell the 1600 px banner from the 800 px card image. Always compress from the original, not from an earlier WebP, because every extra pass adds artefacts.

For a batch of banners, load them together and process one at a time. The queue holds up to 12 images and 48 MB of input, and finished results can be saved as a ZIP with numbered file names. Completed outputs are retained up to 64 MB, so a very large set should be split. Record the quality value you used, such as 78, in your notes.

The mistake to avoid is sending WebP to someone who then cannot open it. When you hand files to a client, include a JPG or PNG alongside, plus one line about dimensions and the quality used. Keep the originals in a separate folder so you can re-export at a different setting later.

WebP still image

WebP still export

Compression happens in your browser, so the images are not uploaded; unsaved results are lost when you close the tab.