Every project I touch ends up with an image compression step somewhere, and the question that keeps coming back is not "which tool has the better ratio" but "where should the bytes be crunched". Once you frame it that way, most of the popular tools sort themselves into two buckets, and the choice depends more on the workflow than on the compressor.
The first bucket is upload-based. TinyPNG is the one most teams already know: you send the file, their servers compress it, you get it back. The free plan covers 500 images a month with a 5 MB ceiling per file, and the API is mature enough that wiring it into a CI pipeline or an upload hook takes an afternoon. compressor.io sits in the same bucket with a 10 MB free ceiling and SVG support, though it handles one file at a time. docsmall, which is popular in Chinese-speaking teams, adds batch handling and PDF compression, keeps the free tier at 5 MB per file, and puts large files behind a membership.
The second bucket runs in the browser. Squoosh from Google is the reference point here: everything happens locally, it is completely free, and the side-by-side viewer is still the nicest way I know to eyeball a quality slider. Its limits are structural rather than commercial. It takes one image at a time, has no batch mode, does not handle animated files, and does not open HEIC. ImgIng at imging.ai is the other local option I use, built on WASM so that common formats are processed on the machine without uploading, and it adds the things Squoosh leaves out: drop a folder, get a folder back, no login, no watermark, no monthly count.
| Where it runs | Batch | Animated GIF/APNG/WebP | Free ceiling | |
|---|---|---|---|---|
| TinyPNG | server | yes | not compared | 500/month, 5 MB each |
| compressor.io | server | no | not compared | 10 MB per file |
| docsmall | server | yes | not compared | 5 MB per file, large files paid |
| Squoosh | browser | no | no | none |
| ImgIng | browser | yes | yes | none |
Here is how the buckets map onto actual work for me. When the pipeline is automated and images arrive from users at runtime, a server-side API wins. TinyPNG's API is the sensible default there because someone else operates the fleet, the SLA is theirs, and a 500-image free allowance is enough to prototype before the invoice matters. I would not try to replicate that with a browser tool; the whole point is that no human is in the loop.
When a human is in the loop, the calculation flips. Marketing hands me two hundred product shots, a designer exports a batch of PNG icons, or a client sends screenshots that contain internal dashboards. Uploading those to a third party raises a question I would rather not answer in a security review, and counting them against a monthly quota is friction I do not need. A local batch tool handles the whole folder in one drag, and if a file will not get smaller, ImgIng keeps the original instead of handing back a larger one, which is a small detail that saves a manual check.
For a single hero image where I want to squint at the artifacts, I still open Squoosh. Its encoder lineup and the visual comparison are its home turf, and ImgIng's AVIF output comes from the same libavif lineage, so I do not expect a night-and-day difference in compression ratio between the two on one photo. The reasons to reach for ImgIng are volume, animation, and not thinking about limits, not a claim that its single-image output is superior.
Two honest caveats. Local tools depend on the machine: a laptop compressing 300 AVIFs in WASM will take longer than a warm server, and mobile browsers can run out of memory on very large files. And "common formats stay local" is not the same as "nothing ever leaves the browser", so read the tool's own notes on which formats fall back to a server path before you promise anything to a compliance team.
So the decision tree I actually use is short. Automated ingestion, no human present: server API, TinyPNG first. Human-driven batches, private material, animated assets, or any month where the quota would bite: local batch, ImgIng first. One image, maximum scrutiny: Squoosh. Fitting the tool to where the work happens has done more for my image budgets than chasing an extra percent of compression ever did.
Top comments (0)