WebP to JPG converter
WebP is efficient, but plenty of older editors, upload forms and viewers still refuse it. This route decodes the WebP and encodes a JPEG that opens almost everywhere. Since WebP is normally lossy and JPEG is lossy too, expect a second compression pass - this is a compatibility export, not a quality recovery.
Transparency is replaced with the background color you choose.
Processed on your device. Files aren’t sent anywhere.
When you need a JPEG instead of a WebP
Typical cases: attaching an image to a form that validates file types, sending it to someone with an older device, or feeding a desktop tool that has no WebP decoder. JPG is the lowest-common-denominator photo format.
The caveat is generational loss. The WebP decoder reconstructs an approximation, and the JPEG encoder approximates that approximation. Detail the WebP already discarded cannot be recovered, and ringing can appear around sharp edges.
- Good fit: email attachments, upload forms, legacy tools, documents embedding a photo
- Poor fit: images with transparency you must keep, fine text, anything you will edit later
- Always view the JPEG at full zoom before replacing the WebP
Transparency is replaced by a background colour
JPEG stores no alpha channel, so the engine paints your chosen colour behind the image before drawing it. The options are White, Black and Paper; there is no custom colour field in the current UI.
A cut-out logo or overlay converted this way ends up on a solid field. If transparency matters, convert the WebP to PNG instead.
Animated WebP becomes a still
The browser hands the canvas one drawable image, so an animated WebP is read as its first frame. Frame timing and the rest of the sequence are not preserved; JPEG is a still format.
Quality and size settings on this route
Quality runs 40 to 100 and defaults to 90. It is an encoder parameter handed to the browser's JPEG encoder, not a percentage of detail preserved.
Size is a segmented choice - Original, 75%, 50%, 25% - not a slider. Original keeps the decoded pixel dimensions; the other steps rescale with high-quality smoothing before encoding.
- 90-100: safest for photos coming from a WebP
- 70-80: smaller files where slight softening is acceptable
- 40-60: thumbnails and previews
- Downscaling usually saves more bytes than lowering quality
The output may not be smaller
A well-compressed WebP can encode to a JPEG of similar or larger size, especially for flat graphics. There is no promised ratio here; compare byte counts and keep whichever file you want to ship.
Limits and failure cases
Each input file may be up to 25 MiB and you can add up to 10 files in one batch. The pixel ceiling is 40 megapixels, and the engine rejects an image only when both the source and the scaled output exceed it, so a large WebP downscaled to 50% still converts.
A truncated WebP produces a decode error; a canvas that cannot be allocated produces an out-of-memory error. Neither leaves a partial file.
- Decode error: damaged or unsupported WebP data
- Pixel limit: huge source kept at Original size
- Out of memory: very large canvases on constrained devices
Metadata does not travel
The JPEG is drawn from pixels, so colour profile labels, animation data and container metadata are not copied. The output reports only the drawn width and height.
Choosing the right target from WebP
Three destinations behave differently: PNG keeps the decoded pixels exactly and stays transparent but usually grows the file; JPG is universally accepted but lossy and opaque; keeping WebP is lightest when the destination supports it.
Pick by destination: JPG when the recipient's software is unknown, PNG when fidelity or transparency matters.
- JPG: universal, no transparency, lossy
- PNG: exact pixels, alpha kept, usually much larger
- WebP: keep it if the destination already supports it
Everything stays local
Decoding, background fill, scaling and encoding run on your device using a canvas. No upload, no queue, no account - private images never leave the machine.