Converting JPG to WebP

Where JPG came from, and why it is like this

WebP was built to replace JPEG on the web, and at the same visual quality it is usually 25–30% smaller. Those comparisons, though, are made by encoding the same original into both formats. This conversion is a different operation: the JPEG has already discarded detail, and WebP is now being asked to compress the result.

That is not pointless — WebP genuinely encodes the same visual information in fewer bytes — but the saving is smaller than the headline figure, and it is a second lossy generation on top of a first.

Is this conversion lossy?

Yes, and twice. The JPEG artefacts already in the image are now the content being compressed, and WebP will faithfully spend bits preserving them while adding its own smoothing on top. At a high quality setting the second generation is invisible and the file is meaningfully smaller. At an aggressive setting the two artefact patterns compound, and fine texture that survived the JPEG stage disappears at the WebP stage.

The practical rule: if the JPEG was saved at high quality, the conversion is nearly free. If it was already heavily compressed — a photograph that has been through a messaging app, for instance — there is little left to save and the second pass will visibly soften what remains.

What happens to metadata, transparency and colour

EXIF does not survive. A canvas conversion drops it, so the camera settings, the timestamp and any GPS coordinates in the source JPEG do not reach the WebP. Worth knowing in both directions: it is a privacy improvement and an archival loss, and only one of those is usually intended.

The colour profile does not survive either. A Display P3 JPEG becomes an untagged WebP that browsers will read as sRGB, which flattens saturated colour. For photographs on a site that cares about colour, this conversion is worth checking visually before doing it in bulk.

Transparency is not relevant here. The source JPEG has none, so while the WebP could carry an alpha channel, there is nothing to put in it.

Orientation is worth watching. JPEGs from phones are frequently stored rotated with an EXIF orientation flag telling the viewer to turn them. When EXIF is dropped, that instruction goes with it — so an image that looked upright can come out sideways.

Why people actually need this

Almost always a website. A performance audit flags the images, the images are JPEGs from a photographer or a stock library, and WebP is the recommendation. The saving across a page of photographs is real and typically worth a second of load time on a slow connection.

The other case is a content management system that has started serving WebP and wants its back catalogue converted. Here the risk of the second generation is worth taking seriously — bulk-converting an archive of already-compressed JPEGs at a low quality setting degrades every image at once, and the originals are usually gone by the time anyone looks closely.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

And the ceilings measured for Image converter, the tool that performs it, on the hardware described on the limits page:

Not tested

The page also refuses files above 50 MB before it starts, which is a guard written into the tool rather than something the browser imposes. Why those are different.

When something else is the better answer

If you still have the original, uncompressed image, convert that to WebP rather than the JPEG. One lossy generation instead of two, a smaller file, and a better-looking result — this is the single biggest improvement available on this conversion.

If the JPEG is already small or already heavily compressed, skip it. Below roughly 50 KB the saving is a rounding error and the risk of visible degradation is not.

If the image is going to a person rather than a browser, keep the JPEG. Compressing it further is the safer way to shrink a file someone else has to open.