How this compressor works
Every file you drop is decoded to raw pixels, optionally scaled down, and handed to a WebAssembly build of a real production encoder — MozJPEG, libwebp, libaom or OxiPNG. These are the same codecs Squoosh ships.
canvas.toBlob → the browser's default JPEG writer, one quality knob, no way to ask for anything else
That is the difference, and it is not marketing: a real encoder run slowly beats the one the browser hands you, which is why the settings below are worth reading. All of it runs in this tab — no upload, no queue on somebody else's server, and no limit imposed by a plan; the ceiling is your own machine's memory, which is why the file count and megapixel caps exist.
Choosing a format
The format decides more than the quality slider does. A photograph in PNG will always be larger than the same photograph in WebP, whatever the quality is set to, because PNG has no way to throw away what the eye will not miss.
| Format | What it does | Reach for it when |
|---|---|---|
| Match the original | Keeps each file in the format it arrived in, so a JPG comes back a JPG. | Something downstream expects the extension it already has. |
| Smallest of all four | Encodes each file with every codec that suits it and keeps the shortest result. | Size is what matters and you can wait — this is three or four encodes per file. |
| WebP | Lossy or transparent, roughly 25–35% smaller than JPEG at a matched quality. | You want one format that is smaller than JPEG and read everywhere current. |
| AVIF | Usually the smallest of the four on photographs, at several times the encoding cost. | The file is served to browsers you control, and bytes matter more than encode time. |
| JPEG | MozJPEG with trellis quantisation and a progressive scan order. | The file has to open in anything, including software from before 2010. |
| PNG | Rewrites the file losslessly with OxiPNG — same pixels, fewer bytes. | The image is a logo, a diagram or a screenshot of text, where a lossy artefact is obvious. |
JPEG has no alpha channel. Send it a transparent image and this tool composites the picture onto white first and says so on the row, rather than letting the encoder keep whatever colour happened to sit under the transparency — usually black.
Under Smallest of all four, JPEG only competes for an image that is fully opaque, and PNG only competes against a source that was already lossless. Both exclusions save an encode that could not have won.
Every control
Three settings decide the output, and they are applied in the order listed: the picture is scaled first, then encoded at the quality you chose, in the format you chose.
| Control | What it does | Reach for it when |
|---|---|---|
| Quality | Sets the encoder's quality parameter from 10 to 100. Ignored by PNG, which is lossless here. | The default is visibly soft on your image, or is leaving more bytes than you need. |
| Output format | Picks the encoder, or asks for all of them and keeps the smallest result. | See the table above — this is the setting with the largest effect on size. |
| Longest edge | Scales the picture so its longer side is at most the value you pick, keeping the aspect ratio. | A 12-megapixel photograph is going into a page that will display it 800 pixels wide. |
| Compress | Runs every file that has no result yet, one at a time, and reports progress as it goes. Files already compressed are left alone. | You have dropped files in — nothing is encoded until you press it. |
| Compress again (per row) | Re-encodes that one row under the settings showing now, replacing its result. | A finished row has dimmed and you want it done again at the new quality. |
| Download | Saves one result under the original name with -min and the new extension. | You only wanted the one file. |
| Download all (ZIP) | Packs every finished result into one archive, numbering any names that would collide. | There is more than one result and you would rather not click through them. |
| Remove | Drops a single file from the queue along with its result. | One file in a batch was picked by mistake. |
| Clear all | Empties the queue and releases every preview. | You are done, or want to start from nothing. |
Because scaling happens before encoding, a size cap and a lower quality compound: halving the longest edge quarters the pixel count before the encoder ever sees it, which is why the cap usually saves more than the slider does.
Changing a setting never rewrites a result you already have. The finished rows dim, the status line says so, and Compress still only runs the files that have none — so adding a second image at a different quality leaves the first one exactly as it was. Redoing one is the Compress again button on that row.
Picking a quality
Quality numbers are not comparable between codecs. MozJPEG at 75 and libwebp at 75 do not target the same distortion, and AVIF's scale is different again — libaom's own default is 50, which on most photographs looks like JPEG at somewhere in the seventies. Compare the output, never the number.
For photographs, 70 to 80 is the range where the saving is large and the artefacts are hard to find without flicking between the two at full size. Below about 60 the flat areas of sky and skin start to band, and the edges around text pick up a halo. Above 90 the file grows quickly for a difference almost nobody sees. The slider starts at 100 so nothing is thrown away until you choose to; bring it down into that range for the real saving.
Images with hard edges — screenshots, diagrams, anything with text in it — behave differently. A lossy codec spends its bits on the edge and leaves ringing beside it, which is far more visible than the same artefact in foliage. Those are the images to keep as PNG, or to push to 90 and up if they must be lossy.
MozJPEG runs trellis quantisation, which searches for the set of coefficients with the best size-to-distortion trade at your chosen quality instead of taking the first one the quantiser produces. libwebp is set to its slowest analysis mode with sharp YUV conversion, which removes the coloured fringing on saturated edges that people usually mistake for WebP looking worse than JPEG. Both are off by default in a browser because both cost encoding time, and here you are the one waiting.
Downscaling goes through a Lanczos3 filter in linear light rather than through the canvas. Drawing an image smaller with drawImage gives you whatever your GPU driver does, which on a large reduction is a box filter and visible aliasing. Doing the arithmetic in linear light also stops the picture darkening as it shrinks, which is the artefact you see when a bright checkerboard turns grey instead of staying bright.
What happens to metadata
A re-encode starts from decoded pixels, so nothing that was attached to the original file survives: EXIF, GPS coordinates, camera and lens details, capture time, copyright fields, and any embedded colour profile are all gone from the result. That is a privacy improvement most of the time and a loss if you were relying on it — export the metadata first if you need it.
One tag is applied rather than dropped. A phone usually records a rotated photograph the right way up in the pixels and writes an orientation tag saying which way to turn it. Discarding the tag without acting on it is why so many compressed photographs come back sideways, so the decode step applies the rotation to the pixels before anything else happens.
The missing colour profile matters for images that were not sRGB to begin with. A photograph exported in Display P3 or Adobe RGB is decoded to those numbers and written back without the profile that explains them, so a wide-gamut original can come back looking flat. Convert to sRGB before compressing if the source was not sRGB already.
Limits, and why they exist
Up to 40 files can be queued at once, each up to 25 MB, and each up to 40 megapixels once decoded. The last of those is the one that catches people out: a 2 MB PNG can hold a hundred megapixels, and decoded pixels cost four bytes each regardless of how small the file was.
Files are compressed one after another rather than all at once. A parallel run would be faster on paper and would also hold every decoded image in memory simultaneously, which is how a tab crashes halfway through a batch. Sequential work also means the progress count is honest.
AVIF is slow. A large photograph can take several seconds per file, and Smallest of all four runs AVIF alongside the others. That is the trade for the smallest output; if you want a quick answer for a large batch, choose WebP outright.
Where your images go
Nowhere. The codecs are WebAssembly modules running inside this page, so the decode, the resize and the encode all happen on your own machine. There is no request carrying your file, which is why the tool keeps working after the page has loaded and the network has gone.
Nothing is stored either. The queue lives in the page for as long as the tab is open, and the preview thumbnails are object URLs released when you remove a file or leave. Reloading the page loses everything, on purpose.
This matters more for images than for text. A photograph carries where it was taken and often which device took it, and an ordinary online compressor has both the moment you upload. Here the only copy of your file is the one you already had.