convert to
resize
✓ EXIF, GPS and all other metadata are removed from the output.
Drop images here
or click to browse — PNG, JPEG, WebP, GIF, HEIC, AVIF, SVG — you can also paste images (Ctrl+V) anywhere on this page
Move a WebP onto a newer codec — and see the two things that quietly change on the way: the frames and the lossless guarantee.
Your files never leave your browser — all processing is local.
✓ EXIF, GPS and all other metadata are removed from the output.
Drop images here
or click to browse — PNG, JPEG, WebP, GIF, HEIC, AVIF, SVG — you can also paste images (Ctrl+V) anywhere on this page
Animation is the first casualty, and it is the only route out of this source format on the site where the frames do not survive. Animated output exists for two targets, GIF and WebP; anything else takes the still path, so a multi-frame source is probed, recognised, and then closed after its first frame with a warning saying so. Every subsequent frame, every per-frame delay and the loop count are discarded together. If you came here to shrink an animation, re-encoding to the source format itself keeps the motion, and so does GIF at a much higher cost in bytes.
The second loss catches people who use the source format for interface assets. A WebP written in lossless mode is pixel-exact, and there is no way to keep that promise through this conversion: the lossless checkbox in the settings applies to the WebP encoder, not to this one, so the target is always written lossily at the quality on the slider. Flat artwork, icons, screenshots and diagrams — exactly the material lossless WebP exists for — come back approximated, with soft halos where crisp one-pixel edges used to be. Alpha, at least, is untouched: no background is applied and semi-transparent pixels stay semi-transparent.
The rest is the usual toll for rebuilding a file from decoded pixels. EXIF and ICCP chunks in the source's RIFF container are not transferred, so capture data and the color profile are gone and the result is read as sRGB. The decoded buffer is 8-bit, so nothing reaches the encoder that could have used its 10- or 12-bit capability. And because both sides are lossy, this is a second generation: the new encoder cannot separate the first one's smoothing from real detail, and preserves it.
On 2026-09-12 the script measured a 1280 × 854 lossy WebP at quality 85, 319,834 bytes, and re-encoded it to AVIF at quality 85, speed 8: 485,143 bytes. The file grew by about 52%. The widely quoted 15–25% advantage is a comparison of two encoders working from the same uncompressed master at matched *visual* quality, judged on test corpora. Here the second encoder was set to the same number on a different scale — libaom's 85 targets a higher fidelity than libwebp's — and handed an image that had already been quantized once. It duly spent bits reproducing that. Pull the quality slider down and watch the size readout; the number on the slider is not a unit shared between formats.
Do not convert an animation you want to keep animated, and do not convert a lossless asset you want to keep exact — those are the two specific promises this route breaks. Do not re-transcode a library wholesale, because at matched slider positions you may well spend bytes rather than save them, on top of a second lossy generation per file. Do not bother with small assets at all: icons and thumbnails are dominated by container overhead, and the codec has nothing to work with. The conversion is worth making for a large photographic image where you can afford to tune the quality down and compare the result, and it is worth making from an original master rather than from an already-encoded delivery copy.
Conversion happens entirely in your browser — no upload, no queue, no watermark. Drop in as many files as you like and download them individually or as a zip.
No. Only the first frame is kept, and a warning tells you. Animated output is implemented for GIF and for WebP itself, so if the motion matters, re-encode to the source format — it keeps every frame and its delays — or accept GIF and a much larger file.
It comes back lossy. The lossless option in the settings belongs to the WebP encoder, and there is no equivalent for this target, so pixel-exact artwork is approximated at the quality on the slider. For icons and flat graphics that is a downgrade worth avoiding.
Because the setting is not a shared unit. Each encoder maps 85 onto its own quantizer and the newer one aims higher, so it produced a more faithful — and larger — copy of an image that had already been compressed once. The measured sample went from 319,834 to 485,143 bytes.
No. Conversion happens inside your browser using the canvas API and a Web Worker — files never leave your device. There is no upload step, no queue and no file size limit beyond your machine's memory.
No — and that's a feature. Re-encoding through the canvas strips all metadata: GPS location, camera model, timestamps and color profiles. The output contains pixels only, which is usually what you want before sharing an image publicly.
Yes. Drop or paste any number of files; each is converted in the background with its own progress and download button, and you can grab everything at once as a .zip archive.
It depends on the target. The converter always decodes to raw pixels and re-encodes, whichever formats are involved, which is also how metadata gets stripped. For lossless targets (PNG, and GIF within its 256-color limit) the pixels stay identical to what was decoded; for JPEG, WebP and AVIF the quality slider controls the trade-off, and converting a file that is already lossy adds one more generation of loss.