How a WebP file ended up on your disk
Almost nobody creates WebP files on purpose. They arrive because a website served its images in WebP and the browser saved what it received. Right-click and save on a shop listing, a Wikipedia thumbnail, a Google Play screenshot or a news photo, and you get a .webp even when the page looked like it was showing a JPG. The format is excellent for delivery, but the moment you try to attach that file to a print order, drop it into an older version of Word, upload it to a government portal or open it in a photo app from a few years ago, it gets rejected. JPG is the format that has never been rejected by anything, which is why this converter exists.
What is lost when WebP becomes JPG
The file is decoded by the browser, handed to a Web Worker as raw pixels, and re-encoded with mozjpeg compiled to WebAssembly. Nothing is uploaded. Four things change on the way through:
- Transparency disappears. WebP can hold an alpha channel; JPG cannot. The encoder drops it, and because fully transparent pixels carry black underneath, transparent areas typically come out black. If your WebP is a logo or cut-out on a transparent background, use WebP to PNG instead.
- Animation is reduced to one frame. Animated WebP is common on messaging apps and sticker packs. The browser decoder returns only the first frame, and that is what the JPG contains.
- A second round of lossy compression is applied. Most WebP files on the web are lossy. Encoding them to JPG adds JPG's own artefacts on top, so choose a higher quality than you normally would.
- Metadata is not carried over. WebP can hold EXIF and an ICC profile; the canvas decode applies the profile, converts to sRGB, and discards both. The JPG is progressive, 8-bit and has the same pixel dimensions as the source.
If the source was a lossless WebP, for example a screenshot or a graphic exported from a design tool, the JPG will be the first lossy step, and text and fine lines will show slight ringing.
Quality and size expectations
The slider goes from 20 to 95 and starts at 80. Because you are compressing already-compressed pixels, 85 to 90 is the sensible range here; the extra bytes protect against the two codecs' artefacts stacking. Going to 95 gains almost nothing visible over 90 at a large size cost.
Unlike most conversions on this site, the JPG is usually bigger than the WebP it came from, because JPG is the less efficient codec. Typical outcomes:
- A 1000x1000 product photo of 85 KB as WebP comes out around 150 to 220 KB as JPG at quality 85.
- A 1920x1080 article image of 180 KB as WebP usually lands between 320 and 480 KB.
- A 512x512 sticker of 30 KB as WebP, on a transparent background, becomes a 40 to 60 KB JPG with a black background, which is rarely what anyone wants.
When JPG is the wrong destination
Choose PNG when the image is a graphic, contains text, or has transparency; the file will be larger but nothing degrades. Keep the WebP if the file is only going onto a website you control, where every browser will display it. And if you are converting purely to get under an attachment limit, the JPG will be larger, not smaller; Compress image with a resize is the tool for that job. The guide WebP vs AVIF vs JPEG explains when each format earns its place.
Limits to be aware of
The browser does the decoding, so a WebP that your browser cannot open cannot be converted; every current browser handles both lossy and lossless WebP, but very old Safari versions on macOS Catalina and earlier do not. Large images are limited by canvas memory on your device. CMYK and 16-bit output are not possible; the result is standard sRGB JPG. Several files can be queued together and are converted one at a time, each with its own download button.