Move an image between PNG, JPEG and WebP without uploading it. Each format is good at something different, and picking the wrong one can multiply your file size rather than reduce it.
Runs in your browser. Nothing is uploaded.
These three formats make different bargains. PNG is lossless: it reproduces every pixel exactly and supports transparency, which makes it right for logos, screenshots, diagrams and anything with sharp edges or flat colour. JPEG discards detail the eye is weak at noticing and has no transparency, which makes it right for photographs. WebP does both jobs, with a lossy mode that is more efficient than JPEG and a lossless mode that usually beats PNG, and is supported by every current browser.
On the same 3840x2160 photograph, converting to WebP at quality 0.92 produced 1,490,806 bytes while JPEG at the same setting produced 1,825,404: WebP is about 18 percent smaller for visually equivalent output. The direction that surprises people runs the other way. Converting that photograph from JPEG to PNG took it from 2,057,152 bytes to 16,015,580, nearly eight times larger, because PNG faithfully stores photographic noise that JPEG had been throwing away. PNG is not a higher quality version of a JPEG. Once detail has been discarded, storing the result losslessly preserves the loss at great expense.
Choose an image
The same questions a security review would ask, answered plainly.
Measured at 18 percent smaller than JPEG on the same photograph at the same quality. Every current browser reads it, so the compatibility argument against it has expired.
PNG and WebP both carry an alpha channel, so converting between them preserves transparent backgrounds. JPEG cannot, which is worth knowing before converting a logo.
The image is decoded and re-encoded by your own browser. Nothing is transmitted, so unreleased artwork and personal photographs stay where they are.
PNG to JPEG took 200 milliseconds on a 4K photograph and PNG to WebP 669. WebP costs more encoding time for its extra efficiency, which matters only in bulk.
There is no upload step and no server to receive one. The page loads once, then all work on your images happens in local JavaScript.
No daily limits, no per-file ceilings imposed by a server tier, no watermarks, and no account. The practical limit is your own device's memory.
One that saves most of the file, and one that multiplies it.
The conversion with the best return on a photographic source.
Input
3840x2160 PNG, 10,887,764 bytes
Output
WebP, 1,490,806 bytes, 86.3% smaller, 669 ms
Settings: Quality 0.92
Eighty-six percent removed from a lossless original. The same source converted to JPEG at the same quality came out at 1,825,404 bytes, so WebP saved a further 18 percent for about three times the encoding time.
The conversion people expect to improve things, which does the opposite.
Input
3840x2160 JPEG, 2,057,152 bytes
Output
PNG, 16,015,580 bytes, 678% larger, 306 ms
Nearly eight times the size, and not one pixel better. PNG stores exactly what it is given, and what it was given had already had detail removed by JPEG. Converting to PNG protects an image from further loss in editing; it cannot undo loss that already happened.
Real files, real numbers, and the machine they were run on.
| Scenario | Input | Output | Time | Notes |
|---|---|---|---|---|
| the photograph, PNG to WebP at quality 0.92 | 10,887,764 bytes | 1,490,806 bytes | 669 ms | 86.3% smaller |
| the photograph, PNG to JPEG at quality 0.92 | 10,887,764 bytes | 1,825,404 bytes | 200 ms | 83.2% smaller, 18% bigger than WebP |
| the photograph, JPEG to PNG | 2,057,152 bytes | 16,015,580 bytes | 306 ms | larger, and no better |
How this was measured: Measured by driving this page in headless Chrome 152 on an Apple M4 Pro running macOS 15.5, on 2026-09-17. The fixture is handed to the page's own file input, the page's own button is pressed, and the figure recorded is the size of the file the page produces. Timings come from a warm page on a fast machine with no network involved, so treat them as a floor rather than a typical result.
WebP, with JPEG as a fallback only if you still support browsers old enough to need it. The measurement above puts WebP 18 percent below JPEG at matched quality on the same image, and that saving applies to every visitor.
Convert to WebP rather than JPEG. Both PNG and WebP carry an alpha channel, so the transparency survives. JPEG has none, and the transparent areas will come back filled in.
Convert it to PNG if you need it lossless for editing, or JPEG if it is a photograph and size matters. Most software reads WebP now, but older desktop applications sometimes still do not.
Only to stop further loss. If an image is about to go through several rounds of editing and saving, working in PNG prevents each save from degrading it again. It costs a great deal of space and recovers nothing already lost.
Switching photographic assets to WebP is one of the few changes that reduces page weight substantially without any visible difference. On a media-heavy page the saving compounds across every image.
Logos and interface assets need lossless formats with transparency, while the photographs alongside them do not. Converting each to what suits it avoids shipping everything as the heaviest common denominator.
Upload forms frequently accept only JPEG or PNG and reject anything else. Converting locally is faster than finding software that will, particularly on a managed machine.
Modern phones produce formats that older desktop software cannot open. Converting to JPEG or PNG makes an image portable without involving a service that would keep a copy.
A library of PNG exports converted to WebP typically loses most of its size. Doing it locally means archives of personal or client images never leave the machine.
Embedding lossless photographs in a report inflates it enormously. Converting them first keeps the document small enough to email without anyone noticing a difference on screen.
Starting with the conversion that costs you the most.
Measured at nearly eight times the original on a 4K image. PNG is the right choice for graphics and the wrong one for photographic content, and it cannot restore detail an earlier lossy save removed.
JPEG has no alpha channel, so transparent regions are flattened during conversion. A logo intended to sit on a coloured background will come back with a background of its own.
There is no slider here; the setting is high enough to be visually lossless on photographs and therefore conservative on size. Use the compressor when you want to trade visible quality for a smaller file.
The browser can decode more formats than it can encode, so a GIF or an SVG can go in but not come out. Animated inputs are flattened to their first frame, and AVIF output is not available.
No. Decoding and re-encoding are both done by your browser, and no request leaves the page while you work. The conversion also runs perfectly well with the network disconnected, which is the clearest demonstration that no server is involved.
Yes, measurably. The same photograph at the same quality setting produced 1,490,806 bytes as WebP and 1,825,404 as JPEG, so WebP was about 18 percent smaller. It took roughly three times as long to encode, which is irrelevant for one image and worth considering for thousands.
Every current browser does, including Safari since 2020. The remaining gaps are old operating systems and some desktop applications, so WebP is safe for the web and occasionally awkward as an interchange format with other software.
No, and this is the most common misunderstanding about formats. PNG stores precisely what it is handed. Detail a JPEG encoder discarded is not in the file any more, so converting preserves the degraded version at roughly eight times the size.
It survives conversion to PNG or WebP, both of which have an alpha channel, and is lost converting to JPEG, which does not. Convert transparent graphics to WebP if you want them smaller without losing the transparency.
Only its first frame. The image is drawn once to a canvas, so animation is not carried through and you get a still. Converting animation needs a video or animated WebP encoder, which this is not.
No. The image is drawn at its natural size, so the pixel dimensions are identical afterwards and only the encoding changes. Resize separately if the image is larger than it needs to be.
No. Only pixels pass through the canvas, so camera information, capture time and GPS coordinates are dropped. Useful before publishing a photograph, inconvenient if you were depending on those fields.
PNG, or lossless WebP. Screenshots are full of text and sharp edges, exactly what lossy encoders handle badly: a JPEG screenshot shows fringing around letters that makes small text harder to read.
Not here, it is one at a time. That fits converting an asset or two and is impractical for a library, where a desktop batch tool or a build step will serve you better.
Because WebP does more work to achieve its smaller output. On the 4K photograph it took 669 milliseconds against 200 for JPEG, and returned a file 18 percent smaller in exchange.
Yes, once the page has loaded. The encoders are part of your browser rather than something fetched, so conversion continues to work with no connection at all.
There is no limit imposed by us, because there is no server tier to enforce one. The real constraint is your device's available memory, since the whole file is held in RAM while it is processed. Very large files are slower on phones than on a laptop.
No. There is no sign-up, no email, and no usage tracking tied to an identity. The tool works the first time you open it.