This tool moves an image between JPEG, PNG and WebP: the source is decoded, redrawn onto a canvas at its original dimensions, and written out again by the browser's built-in encoder in the format you pick. The pixel grid is untouched — what changes is the encoding around it, and with it the file size and whether transparency survives.
How to use it
- Drop an image on the panel first. The rest of the controls are rendered only once a file exists, so an empty page below the panel is expected.
- Choose one of the three buttons under "Output format": JPEG, PNG or WebP. WebP is selected by default, and the active button is outlined in the accent colour.
- With JPEG or WebP selected, a "Quality: 90%" slider appears underneath (range 1–100). Switching to PNG removes the slider entirely, because PNG is lossless and takes no quality parameter.
- Press Convert. When it finishes, a line reading
original size → new sizeappears beside the button — the quickest way to judge whether the conversion was worth doing. - The button next to the preview is labelled for your target, "Download WEBP" and so on. The saved file keeps the original name with its extension swapped; no prefix is added.
- To compare quality settings, move the slider and press Convert again — the figures do not recompute on their own.
When it comes in handy
Switching PNG screenshots on a site to WebP
Interface screenshots in documentation and product pages typically shed 30–50% of their weight as WebP while keeping transparency. Read the size comparison before committing: for a handful of images with very few distinct colours, PNG genuinely wins, and swapping formats for fashion helps nobody.
Turning a WebP you were sent back into JPEG
Almost anything saved from the web today arrives as WebP, while plenty of upload forms, slide templates and print intake processes still accept JPEG only. Converting is the path of least resistance, at the cost of any transparency being flattened — worth confirming before you send it on.
Measuring all three formats on your actual image
Rather than trusting the rule that WebP always wins, run the same picture through three times and read the byte counts the tool prints after each pass. Photographs, flat illustrations and text-heavy screenshots do not rank the same way, and a measurement on the file in front of you beats a remembered generalisation.
Normalising mixed assets before the next step
A folder collected from several sources is usually part PNG, part JPEG, part WebP, and pipelines — contact sheets, PDF assembly, automation scripts — tend to trip on exactly one of those. Converting everything to one format first (PNG when transparency matters, WebP when size does and the toolchain accepts it) removes a whole class of special cases downstream.
Limits and behavior
- Converting to JPEG turns transparent areas black, and it is the single most common surprise here. The code does not paint a background before drawing, and JPEG has no alpha channel, so pixels that were transparent are written with all-zero RGB values — which reads as a solid black block. Cut-out logos and screenshots with rounded drop shadows are the usual casualties. Composite a background elsewhere first if you need white, or choose WebP, the only option here that combines transparency with lossy compression. (Worth knowing: the image compressor next door does paint white before writing JPEG, so the two tools genuinely behave differently on this point.)
- Every conversion is a full decode, redraw and re-encode rather than a repackaging of existing bytes. Even source and target being the same format costs another generation of quality, so always start from the most original file you have instead of chaining conversions.
- Choosing PNG guarantees a lossless output, which is also why JPEG to PNG nearly always inflates the file: the encoder faithfully preserves every compression artefact of the source, pixel by pixel, and two to three times the original size is routine. The reverse direction shrinks dramatically, but only by discarding detail permanently.
- Output dimensions always match the source, and there are no width or height fields on screen. To change both format and size, run the file through the resizer first.
- After selecting a new file but before pressing Convert, the size comparison line may still show the previous image's result: picking a file clears the preview but not the stored output size. Pressing Convert refreshes it, so a stale-looking number at that moment is not a sign of anything worse.
- A file the browser cannot decode leaves the button stuck on "Converting…" forever, because the code only finishes up in the image's load handler and nothing handles a failure. An iPhone HEIC, or a file whose extension disagrees with its contents, is the usual trigger; reload the page to recover.
- Animated GIF and animated WebP keep only their first frame, and SVG is rasterised at a fixed size. None of the three is rejected on drop, since the check looks only at whether the MIME type starts with
image/. - Re-encoding drops EXIF, which is a small privacy win before publishing: GPS coordinates and capture times do not travel with the picture.
- The download name replaces everything after the last dot in the original filename. A source file with no extension at all therefore produces a name consisting of nothing but
.webp, which you can rename after saving. - One image per conversion, 10 MB per file, and no AVIF, HEIC, GIF, BMP, ICO or SVG among the outputs — the three buttons on screen are the complete list, with no hidden settings behind them.
Frequently asked questions
Is my image uploaded?
No. Decoding and encoding both use capabilities built into your browser; the data enters through URL.createObjectURL and leaves through canvas.toBlob, and no step in between sends it anywhere. (The page does carry third-party resources such as advertising, and none of those requests contain your picture.)
My transparent logo came out with a black background. Can I fix it?
Not from the converted file — the transparency was discarded at encode time, so go back to the original. If the destination accepts WebP, convert to that instead and the alpha channel survives untouched. If it must be JPEG, flatten the logo over a white rectangle in any image editor (a slide deck will do in a pinch), export something with no transparency, and convert that.
Is WebP safe to use now?
In browsers, yes — every major one has displayed it for years. The friction is everywhere else: older Office builds, upload validators in content management systems, print shop intake specifications and a number of desktop image viewers. Use it freely on the web; ask first when handing a file to someone else.
Does quality 90 mean the same thing for JPEG and WebP?
No — the two encoders use different scales, and at the same number WebP is usually meaningfully smaller at comparable visual quality. In practice WebP looks excellent around 75–85, while JPEG is better kept above 70. The default of 90 here is a deliberately safe setting; pull it down and let the size comparison tell you where to stop.
Is this a lossless conversion?
Only the PNG output is lossless, and a lossless output is not the same as a lossless round trip: detail a JPEG source already threw away does not come back by wrapping it in PNG. Targeting JPEG or WebP is explicitly lossy, and each pass spends a little more quality.
Can it produce AVIF, or read HEIC?
Neither. The output list is exactly the three buttons, with no AVIF among them, and the input side is limited to what the browser can decode. HEIC fails to open in most desktop browsers, which is the case that leaves Convert stuck. For iPhone photos, either switch the camera to "Most Compatible" so it shoots JPEG, or export a JPEG copy with the system tools before coming here.