Why re-encode a JPG at all
JPG is already a lossy format, so converting one into WebP means compressing an image that has been compressed once before. That is worth doing for one reason: the same picture, at a quality most people cannot tell apart, is typically 25 to 35 percent smaller as WebP. On a website that serves thousands of product photos, that gap is real bandwidth and real load time. On a single photo you are emailing to a friend, it is not worth the trouble.
The conversion here is done by libwebp compiled to WebAssembly, running inside a Web Worker on your device. The JPG is decoded to raw pixels, then encoded fresh. The original file is untouched and nothing is uploaded.
Generation loss, and how to keep it small
Every lossy encode discards a little information. When the input was itself a JPG, the encoder is now trying to describe both the photograph and the faint blocks the previous encoder left behind. At sensible settings the second pass is nearly invisible, but it compounds if you repeat it, so the rule is simple: convert from the highest quality original you have, and do not convert a WebP back to JPG and forward again. If the original JPG is a low-quality download, expect the WebP to inherit its flaws rather than hide them.
The slider runs from 20 to 95 with 80 as the default. For photographs, 75 to 82 gives a file that is clearly smaller than the source without visible change at normal viewing size. If the JPG was saved at a high quality and you care about fine texture, hair or fabric, use 85. Values above 90 rarely justify their size for a photo. Below 60, WebP starts to smooth skin and foliage into plastic-looking patches, which is its characteristic failure, different from the ringing you see in a low-quality JPG.
Typical file sizes
These are typical outcomes from real photos and will vary with subject and the quality of the source:
- A 4032x3024 phone photo of 2.8 MB usually lands between 1.3 and 1.9 MB at quality 80.
- A 1600x1067 web-sized photo of 420 KB usually comes out at 220 to 300 KB.
- A 1200x1200 product shot on a white background, 260 KB as JPG, often drops to 110 to 160 KB, because WebP handles flat areas very efficiently.
Note that the quality numbers of the two formats are not on the same scale. A WebP at 80 is not the same thing as a JPG at 80; compare the results by eye, not by the number.
What the file loses on the way
The decode goes through a canvas, which has two side effects. First, all metadata is gone: camera settings, capture time, GPS position and any copyright field. If that is a feature for you, good; if you need to remove metadata without changing the format, Remove EXIF is the direct route. Second, the orientation tag is applied during decoding, so a portrait shot that was stored rotated comes out upright. Colour profiles are applied and dropped, leaving a standard sRGB image with the original dimensions. JPG has no transparency, so the WebP is fully opaque.
Where WebP still causes trouble
All current browsers display WebP, but the wider world lags. Older versions of Windows Photos and Office, some print services, and a number of government and banking upload forms still reject it. Social networks accept it and then re-encode to their own JPG anyway, so uploading WebP gains nothing there. Use WebP for images you serve on your own site, and keep the JPG for everything else. If you need to go further for a modern audience, JPG to AVIF shaves off more, and How to compress images for the web covers resizing and delivery, which usually matter more than the codec choice.
The only hard limit is memory: extremely large JPGs, 50 megapixels and beyond, may not fit in a browser canvas on a phone, in which case the conversion reports a failure.