Drop in up to 30 JPEGs, PNGs or GIFs and get back WebP or AVIF files, resized and compressed to your settings. Every step runs locally through your browser's own image encoder, so nothing is uploaded, nothing is stored, and there is no sign-up. When it finishes you get the real byte count for each file — not an estimate. In our own 15-image test the median file lost 63% of its weight at quality 80.
Nothing queued yet. Your files stay on this device — see how that works.
Three steps, and nothing leaves your device along the way.
Drag a whole folder's worth of JPEGs, PNGs or GIFs onto the drop zone, or click to browse. Files queue up so you can adjust settings before committing.
WebP at quality 80 suits most web images. Resize by percentage or cap the maximum width — serving a 4000px file into a 800px slot is the most common waste we see.
Every row shows the real before and after size. Use Compare to wipe between the two versions at full size, then download one file or the whole batch as a ZIP.
All four options in the tool are useful for different jobs. This is the short version; the long version is in our format comparison guide.
| Format | Transparency | Typical size vs JPEG | Browser support | Reach for it when |
|---|---|---|---|---|
| WebP | Yes | 25–65% smaller | Universal | Default choice. Safe everywhere, good compression, keeps alpha. |
| AVIF | Yes | Often 20% smaller than WebP | Very good, not universal | Large hero photos where every kilobyte counts and you can serve a fallback. |
| JPEG | No — flattened to white | Baseline | Universal | Email, older CMS uploaders, or anything that chokes on modern formats. |
| PNG | Yes | Usually larger | Universal | Screenshots, flat graphics and line art where you want zero loss. |
WebP usually produces smaller files than JPEG or PNG at the same visual quality. Here is what that actually buys you.
When we ran 15 real images through this tool, the median file dropped 63% at quality 80 — already-JPEG photos alone gave up about half their weight. Lighter images paint sooner, which is the single biggest lever on Largest Contentful Paint.
Most online compressors upload your files to a server first. This one doesn't — it uses the browser's HTML5 Canvas API to do the work locally. Handy for unreleased product shots, client mockups, or anything under NDA.
On phones and slow connections, image weight is usually the main thing between a tap and a rendered page. Smaller files download faster, so visitors wait less — which tends to cut bounce rates on image-heavy pages.
WebP uses predictive coding, which generally avoids the blocky artifacts JPEG shows at low quality. Around quality 80 the result is usually hard to distinguish from the original — use the Compare button to check that on your own files rather than taking our word for it.
Most online image compressors upload your file to a server, process it there, and send the result back. That works, but it means waiting on a round trip and trusting a third party with your image.
WebPMagic does the conversion in the browser instead. When you add a file, JavaScript decodes it — using createImageBitmap() where available, so EXIF rotation is honoured — and draws it onto an off-screen <canvas> at your chosen size. Redrawing also discards the EXIF blocks and embedded colour profiles that bloat camera files. The canvas is then handed to canvas.toBlob(), which invokes the browser's built-in encoder for the format you picked.
Because the encoder is the browser's, output can differ very slightly between Chrome, Firefox and Safari on the same settings. The difference is normally a few percent in file size and invisible on screen — and it's the same encoder those browsers use to display the result, so nothing is lost in translation.
Memory, not bandwidth, is the ceiling. Everything runs locally, so the practical limit is your device's RAM rather than a server quota. A modern laptop handles a 50 MB photo without complaint; an older phone may pause on a print-resolution file. Scale it down first if that happens.
Re-encoding can backfire. Converting an already-compressed file at high quality occasionally produces a larger result, because the encoder faithfully preserves the artifacts already baked in. The savings column tells you the moment that happens, and dropping quality to 75–80 almost always fixes it.
More answers on the full FAQ page, and definitions for anything unfamiliar in the glossary.
We stopped quoting the “25–34% smaller” averages and ran our own test: 15 real photos, screenshots, and logos through WebP at quality 80. The median file shrank 63%, the set went from 6.1 MB to 1.5 MB, and one image got bigger. Here are all the numbers.
11 min read
Everyone says “use quality 80” and nobody says why. We re-encoded the same four images at nine quality steps from 30 to 100 and recorded the file size at each stop, so you can see exactly where the curve flattens and where the artifacts start.
10 min read
A diagnostic guide, not a listicle. Each mistake comes with the symptom you would see in DevTools or PageSpeed Insights, why it happens, and the exact fix — including the three that show up on almost every site we look at.
12 min read
WebP support is effectively universal in browsers now, but browsers are not the only thing that consumes your images. Here is the current support matrix, the places WebP still breaks, and four fallback patterns ranked by how much work they cost you.
10 min read
WebP is no longer the only modern format worth your attention. We compare AVIF, WebP, and JPEG XL on compression, browser support, encode cost, and the features that actually decide the choice — then give you a decision table.
11 min read
Serving one giant image to every device wastes bandwidth on phones and looks blurry on retina displays. Learn how srcset, sizes, and the picture element let the browser pick the right file for every screen — and why sizes is the attribute everyone gets wrong.
12 min read
