Picture Batch JPG to WebP
JPG to WebP
WebP stores a photograph at roughly the same visual quality as JPEG in about a quarter to a third fewer bytes, and every current browser displays it. For a site full of photographs, converting the lot is one of the few page-weight changes that is both large and genuinely free of downsides.
Drop JPEG images here
JPEG files — or any of PNG, WebP, AVIF, BMP, ICO, TIFF, GIF or camera raw (CR2, CR3, NEF, ARW, DNG, RAF, ORF, RW2). Everything runs on this device.
Your images never leave this device. They are decoded and re-encoded by your own browser, and the security policy on every page blocks this site from sending them anywhere.
Smaller than JPEG and PNG, keeps transparency, supported by every current browser.
The usual range for photographs on the web.
Images keep their original dimensions.
Kept. WebP stores a full alpha channel, so cut-outs and soft edges come through exactly.
Exif is carried across where both formats can hold it. Nothing currently in the queue has any.
Exif metadata can be carried from JPEG to WEBP. Colour profiles are not, because decoding converts the image to sRGB.
What happens to your image
Expect a smaller file than JPEG or PNG at the same visual quality, typically by 25–35%.
| Property | Outcome |
|---|---|
| Transparency | Preserved: JPEG images have no transparency to lose. |
| Image quality | Partly preserved: WebP is lossy: the image is re-compressed and detail is discarded to make the file smaller. The quality control decides how much. |
| Generation loss | Partly preserved: Both formats are lossy, so this is a second round of compression on top of the first. It cannot restore anything the JPEG already threw away, and at a low quality setting it will add its own losses. |
| Colour | Partly preserved: Converted to sRGB. Decoding an image colour-manages it into the browser's own space, so the output is sRGB and is left untagged, which every viewer reads as sRGB. A wide-gamut source is reported before conversion. |
| Exif metadata | Preserved: Carried across if you leave metadata switched on, or removed completely if you switch it off. Camera, date and any location tag travel together. |
| Orientation | Preserved: Applied to the pixels, and the tag is reset to upright afterwards so nothing rotates the image a second time. |
This is a second compression, so do not go low
Your JPEG has already discarded detail. Re-encoding as WebP discards more, and the two sets of artefacts compound rather than cancel. Around quality 80 the result is generally indistinguishable from the JPEG at a useful size saving. Going below 65 to chase a smaller file tends to produce something visibly worse than the JPEG you started with, which defeats the exercise.
If you have the original uncompressed image, converting that directly to WebP will always beat converting the JPEG.
Keep the JPEG as a fallback
Browsers handle WebP universally, but email clients, older phones and a lot of desktop software do not. On the web the right pattern is a picture element offering WebP with the JPEG as a fallback, rather than replacing the original outright.
Metadata and orientation
Exif from the JPEG can be carried into the WebP, including the camera and any location tag — or removed entirely, which is worth doing for anything being published. Either way the rotation is applied to the pixels and the orientation tag reset, so the image is upright everywhere rather than upright in some viewers only.
If something goes wrong
The WebP is not much smaller than the JPEG.
The JPEG was already heavily compressed, so there is little left to save.
What to do: Check the original file size in the queue. Below about 100 kB for a full-size photograph, the JPEG is already near the limit.
The WebP is larger than the JPEG.
The quality is set higher than the JPEG's own effective quality, so WebP is faithfully storing artefacts.
What to do: Lower the quality to 75 or so. The result warns you when the output came out larger than the input.
Questions
Does converting JPG to WebP lose quality?
Yes, a little — it is a second lossy pass. At quality 80 the difference is very hard to see, and at that setting the file is usually substantially smaller.
Should I use WebP or AVIF?
AVIF files are smaller again, typically by another 20 to 30%, and it handles gradients better. WebP encodes far faster and is supported by more software. For a large batch in a browser, WebP finishes in a fraction of the time.