Lossy and lossless are different questions
“Compress this image” means two completely different operations depending on the format, and picking the wrong mental model is why people are so often disappointed by the result.
For JPEG, WebP and AVIF there is a quality dial. Turning it down discards detail the eye is unlikely to notice, and the file gets dramatically smaller — halving a photo’s size usually costs nothing visible. The trade is real but generous, and it is why these formats exist.
For PNG there is no dial at all. The format is lossless by definition, so the only thing that can improve is how efficiently the same pixels are encoded. That gets you 10–25% on a typical screenshot and close to nothing on a photograph. Anyone promising to shrink a photographic PNG by 80% without changing the pixels is either converting it to another format or not telling you the truth.
Compressing to a specific file size
“Under 200 KB” is a far more common requirement than “quality 78” — upload forms, email limits and marketplace rules are all expressed in bytes. A quality slider cannot answer that question, because the bytes a given quality produces depend entirely on the picture: a busy landscape and a plain portrait at identical settings can differ threefold.
The lossy compressors here take the target directly. They encode, measure, adjust and repeat, converging on the highest quality that fits under your limit. If the target cannot be met even at the lowest quality, they say so instead of quietly returning something over the line.
Resize before you compress
The single biggest saving is usually not compression at all. An image 4000 pixels wide displayed in a 400-pixel column carries a hundred times more data than it can show. Halving both dimensions removes three quarters of the pixels before any encoder is involved, and it does so without artefacts — unlike pushing quality down far enough to achieve the same reduction.
A useful order of operations: resize to the largest size you actually need, then compress, then check the result against the original. Every compressor here shows both side by side with a draggable divider, so you can see exactly what a setting costs before you commit to it.
Why there are no limits here
Compression runs inside your browser using WebAssembly builds of the same encoders desktop software uses — mozjpeg, libwebp, oxipng. Your file is read from disk into a background worker, processed there, and written back out. Nothing is uploaded, which is why there is no size cap, no daily quota and no account: processing costs us nothing, so there is nothing to ration.