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
Re-encode a JPG as WebP without uploading it — and see honestly how little a second lossy pass actually buys you.
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
Structurally, almost nothing: the source has no alpha channel and no frames, so there is nothing for the new container to drop. The losses are metadata and generations. Every EXIF field goes — capture date, camera and lens, exposure settings, GPS coordinates — along with the embedded ICC profile, because the image is decoded to pixels and encoded again rather than repackaged. For a phone photo that is most of what makes it findable in a library later, and it is also exactly what you want removed before posting it publicly.
Orientation is the one metadata field that behaves differently, and it is worth knowing about. The decoder is asked for the image as it should be displayed, so a photo whose EXIF Orientation says rotate a quarter turn is rotated in the pixel data before encoding. The output therefore appears upright everywhere even though the tag itself is gone. Nothing ends up sideways, but nothing can be rotated afterwards by editing a tag either — the rotation is now part of the picture.
The real cost is that this is a second lossy generation. The source already threw away high-frequency detail in 8 × 8 blocks and already stored color at half resolution. The new encoder cannot tell a block edge or a ringing halo from real detail, so it spends bits faithfully reproducing the previous encoder's mistakes while quantizing once more on top. Turning quality up limits the new damage but cannot repair the old; turning on lossless preserves the artifacts perfectly and produces a much larger file, which is almost never what anyone wants on this route.
On 2026-09-12 the script encoded a 1280 × 854 source to JPG at quality 85 — 351,967 bytes — and then to WebP at quality 85 with @jsquash/webp, giving 317,848 bytes. That is only about 9.7% smaller, far below the 25–35% usually quoted for the format. The quoted figure compares both encoders against the same original master; here the newer encoder was handed an image that had already been quantized at the same quality, so most of the detail it would have saved bits on was already gone. Starting from an original is what makes the gap wide, and it is the reason a mass transcode of an existing library disappoints.
Do not bulk-convert a photo archive. On the measured evidence you would pay a full extra lossy generation on every file for under 10% of the bytes, and you would strip the dates and locations the library is sorted by. If the originals still exist, export from those instead — that is where the format actually wins. Do not convert files destined for an email newsletter, for print, or for an upload form with a fixed extension list. Do not convert images someone may need with EXIF intact, such as evidence photos or anything carrying a licensing or provenance trail. Converting one file for a page whose markup you control, or to see how a hero image looks at a smaller size, is a perfectly good reason.
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.
Because the input had already been compressed at the same quality, so the new encoder had little left to save. The headline 25–35% figure compares both formats against an uncompressed original. Export from the master if you want the full benefit rather than a second lossy pass.
The dates, GPS, camera fields and colour profile are dropped, because the file is rebuilt from decoded pixels. Orientation is the exception in effect: the rotation is applied to the pixels before encoding, so the picture stays upright even though the tag itself does not survive.
Rarely. You would add a lossy generation to every file, lose the metadata the library sorts by, and gain under 10% on the measured sample. Converting selected images for a specific page is worthwhile; converting an archive in place usually is not.
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.