Convert JPG to WebP

If you are here, something has probably told you to do this — a Lighthouse audit, a page speed report, a client asking why the site is slow on a phone. The advice is sound. WebP typically produces a file 25 to 35 per cent smaller than a JPG of the same visual quality, and on an image-heavy page that is the single largest saving available without changing what the page contains.

The support question is settled and has been for a while. Every current browser reads WebP, including Safari since 2020, so a site serving it today is not excluding anyone in practice.

Where it still trips people up is outside the browser: some desktop image viewers, older versions of Office, and the occasional upload form will not recognise the format. WebP is a format for the web, and it is worth keeping the JPG for anything a human might be sent by email.

One thing to be clear-eyed about: converting a JPG to WebP compresses an image that has already lost detail. Your JPG discarded it when it was made, and WebP now compresses what is left. At the default quality the result is visually identical and the saving is real, but you are working from a copy.

If the original photograph still exists as a RAW file, a PNG or straight off the camera, converting that gives a better result at the same file size. In practice most people only have the JPG, and converting it is still worth doing — just do it once rather than round-tripping.

WebP carries an alpha channel, which JPG does not. That matters less coming from a JPG, since there is no transparency to preserve, but it is why WebP can replace both JPG and PNG on a site. A logo that had to be PNG for its transparency and a photograph that had to be JPG for its size can both be WebP, which is one format to serve instead of two.

The honest answer is: AVIF is better, but not yet instead of. It compresses roughly 20 per cent tighter than WebP, at the cost of much slower encoding and thinner support in older software. If your setup can serve both and let the browser choose with a picture element, do that. If you are picking one format and moving on, WebP is the one that works everywhere today.

The conversion runs in your browser, which for this use is a practical benefit rather than a privacy one: you can drop a hundred images from a build folder — the batch cap — and none of them go anywhere, so there is no upload wait and no daily allowance. Take the results as a single ZIP.

A website does not have to pick. The picture element lets you offer WebP with a JPG beside it, and every browser takes the first format it understands — which means the modern ones get the smaller file and the rest keep working, with no user agent sniffing anywhere.

That is worth knowing before converting an entire image library in place. Keep the JPGs, add the WebPs, and the day something in the chain turns out not to read WebP, nothing is lost.

A JPG has already had detail removed. Converting it to WebP removes more, on top of what is gone — the second encoder cannot see what the first discarded and spends its effort on the artefacts instead of the picture. At sensible quality settings nobody notices, and it is still the right move for a page that needs to load faster.

Where it does show is repetition. An image converted, edited, re-saved and converted again accumulates the damage each time. If the original is still somewhere, going to WebP from that rather than from the JPG gives a smaller file and a better one.