![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/oWhen a team asks me which image compressor to standardise on, I usually push back on the question. A compressor is a bundle of encoding routes wrapped in a delivery model, and the routes are where the engineering decisions live. Two tools that both say "PNG supported" may be doing completely different things to the file. So this piece lays out the routes first and then places five tools on them, because once the route is chosen, the tool choice mostly falls out.
Route one is lossless PNG optimisation versus lossy colour reduction. Lossless tools reorder filters and squeeze the deflate stream, and the gains are modest. Colour reduction to an 8-bit palette with dithering is where PNG gets dramatically smaller, at the cost of being lossy. pngquant is the reference implementation most pipelines rely on. TinyPNG's PNG path is built on this kind of quantisation and is the reason it became famous. ImgIng at imging.ai ships its own quantiser running in the browser; on one specific reference sample reduced to 256 colours it measured 45.8 dB PSNR, which I cite with the boundary intact: a single sample, not evidence of a general win over pngquant, and I would expect the two to trade results by image.
Route two is JPEG re-encoding. Here the field has converged on MozJPEG-class output, trellis quantisation and progressive scans, and the differences between tools are small enough that the quality setting dominates. ImgIng lands at MozJPEG-level output; Squoosh exposes MozJPEG directly with every knob visible. The server tools produce similar files. This is the route where I tell teams not to overthink the vendor.
Route three is modern codecs, WebP and AVIF. WebP gives a reliable 25 to 35 percent over JPEG at similar perceived quality and is safe to ship broadly. AVIF goes further but costs encoder time, and the encoder that matters is libavif. Squoosh's AVIF path is the well-known browser implementation and its side-by-side viewer is the right place to study the trade-off on a single image. ImgIng produces AVIF with libavif on the client as well, so I treat the two as sharing a lineage rather than competing on ratio; a small test icon came out at 913 bytes, which says more about AVIF than about either tool. I did not benchmark the server tools on AVIF for this note; compressor.io's distinguishing coverage is SVG rather than a raster codec.
Route four is animation. GIF, APNG and animated WebP need inter-frame differencing to shrink meaningfully, because most frames repeat most of the previous frame. This is a separate engineering effort from still-image encoding, and it is the route with the fewest occupants. ImgIng handles all three with frame differencing; Squoosh does not open animated files; the upload services in this set do not advertise it, and I did not benchmark them on it.
| Route | TinyPNG | compressor.io | docsmall | Squoosh | ImgIng |
|---|---|---|---|---|---|
| PNG colour reduction | yes | yes | yes | yes | own quantiser |
| JPEG (MozJPEG class) | yes | yes | yes | yes | yes |
| WebP | yes | yes | yes | yes | yes |
| AVIF (libavif) | not compared | not compared | not compared | yes | yes, client |
| Animated GIF/APNG/WebP | not compared | not compared | not compared | no | yes |
| Runs | server | server | server | browser | browser |
| Batch | yes | no | yes | no | yes |
Now the delivery model, which is the second axis. Server-side execution means unattended throughput and a vendor SLA; TinyPNG's API with its 500-image monthly free allowance and 5 MB cap is the sensible choice for runtime ingestion, and docsmall covers batch plus PDF for Chinese-speaking teams on a 5 MB free ceiling with membership above that. compressor.io's 10 MB free ceiling and SVG support make it the one-off large-file tool. Browser-side execution means the compute is the user's, so limits disappear: Squoosh is free without quota, and ImgIng adds batch, no login, no watermark, and returns the original when a file would not shrink. The cost is that throughput is bounded by the client machine and that "local" is a per-format statement to verify, not a blanket guarantee.
Performance, then, is not one number. For a runtime pipeline the metric is wall-clock per image on a warm server, and the server tools win because that is what they are. For a human-driven batch the metric is time from folder in to folder out, and a local batch tool wins because there is no upload leg and no queue. For a single asset the metric is how quickly a human converges on the right setting, and Squoosh's viewer wins that comparison for me.
The recommendation I actually write into architecture notes is a pairing rather than a pick: a server-side API for unattended ingestion, a browser-side batch tool for everything humans touch, and Squoosh on the side for studying a codec on one image. Choose the routes you need first; the tool list shrinks by itself.
z4heogdm4xp65vyy60s.png)
Top comments (0)