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
Trade a PNG's exactness for roughly a third of the bytes, without giving up a single transparent pixel.
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
Transparency is safe here, and that is worth stating first because it is the reason to pick this target over JPG: the alpha channel is carried straight through, no background color is applied, and nothing warns you about flattening because nothing is flattened. Animation is the opposite story. The converter implements animated output for exactly two targets, GIF and WebP; AVIF is neither. So a multi-frame PNG is opened, found to be animated, and then closed after its first frame with the warning that only that frame was converted. Frame delays and loop count have nowhere to go. The format itself can hold an animation — this route cannot give it one.
Bit depth runs into a ceiling that belongs to the pipeline rather than the format. AVIF is specified for 10- and 12-bit samples and an HDR transfer function, but the encoder here is handed an ImageData buffer read back from an 8-bit RGBA canvas, so a 48-bit PNG master is quantized to 8 bits per channel before the encoder ever sees it and all of that extra headroom stays empty. Everything outside the pixel grid goes the same way: the source is decoded and re-encoded rather than repackaged, so an embedded ICC profile, gAMA and cHRM chunks, text chunks and any EXIF block are simply not in the output, and a file tagged Display P3 arrives as untagged values a viewer will read as sRGB.
The last loss is the one you are choosing on purpose. This route is lossy and has no alternative: the lossless checkbox in the settings belongs to the WebP encoder, so a pixel-exact PNG becomes an approximation at quality 85 no matter what. Usually a very good approximation — AV1's intra prediction handles flat regions and smooth gradients far better than DCT-based formats — but it cannot be undone, and repeated round trips through it accumulate.
The 2026-09-12 run started from a 1280 × 854 PNG of 1,689,485 bytes, written with "optimize (oxipng)" on (this tool leaves that option off by default), and encoded it with @jsquash/avif at quality 85 and speed 8: 491,861 bytes, about 71% smaller. The speed setting is not a corner cut. Without COOP/COEP headers there is no SharedArrayBuffer, so the encoder always runs single-threaded, and measurements on a 12-megapixel photo put speed 8 at three to five times faster than speed 6 for a size difference under one percent — the difference between a few seconds and a wait long enough to close the tab. Expect a smaller margin on flat graphics, where the PNG was already efficient, and a larger one on noisy photographs.
Keep the PNG when it is animated and the motion matters — target WebP instead, which keeps every frame and is barely larger. Keep it for a 16-bit height map, depth pass or scientific image, where the 8-bit canvas step, not the codec, is what ruins the data. Keep it for anything that has to stay pixel-exact: favicon and app-icon pipelines, sprite sheets a build tool slices by coordinate, screenshots used as test baselines. Keep it for email, where support is still patchy, and for print and prepress, where it is usually refused outright. And think twice before running a large batch on a phone, because the encode is real CPU work per file. For a photograph or illustration headed to a web page you control, this is the biggest single saving on the site.
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 converted and a warning says so, because animated output is implemented for GIF and WebP only. If the motion has to survive, pick WebP — it keeps every frame with the original delays and is usually smaller than the source anyway.
No. The image is drawn onto an 8-bit RGBA canvas before encoding, so the deeper samples are quantized away first. The format could have held 10 or 12 bits, but nothing in this pipeline can hand it more than eight, and the result cannot be restored to the original precision.
Because the output is an AV1 still frame and AV1 encoding is genuinely expensive, while PNG compression is almost free. The encoder runs single-threaded here, since threads would need SharedArrayBuffer and the site does not set the headers it requires. Speed 8 is the setting that keeps it bearable.
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.