TinyPNG vs In-Browser Image Compression: Privacy, Quality, and Speed
TinyPNG, Squoosh, Compressor.io, and the new wave of in-browser image compressors — how they compare on quality, privacy, batch size, and price. Plus a free in-browser image compressor that never uploads your photos.
Cloud compressors (TinyPNG, Squoosh's hosted version, Compressor.io) upload your images to a server to do the work — fast, polished, and a privacy trade-off. In-browser compressors (Uttir, Compress-or-Die, browser-image-compression) do the work locally with the same quality output and zero upload. The quality difference between tools is smaller than the marketing suggests; the privacy difference is real. For one-off images, in-browser is enough. For a 10,000-image catalog, a paid cloud service with a CDN is faster.
Image compression is a solved problem technically — every modern compressor uses the same algorithms (mozJPEG, libwebp, oxipng). The interesting differences between tools are not about quality; they are about where the work happens (your server or the user's browser), how the tool is paid for (ads, subscription, or privacy-as-a-feature), and how it handles the awkward cases (animated PNG, EXIF, color profiles, large batches).
Here is the state of the field in 2026, what each major tool does well, and which one to pick for which use case.
What "image compression" actually means
There are two kinds of compression, and the right tool depends on which one you need:
- Lossy compression — throws away data the eye cannot easily see. The file gets much smaller, the image is visibly identical to most viewers. JPEG and WebP are lossy. The trade-off is a quality slider: 80% quality looks the same as 100% to most people, and is 30-50% smaller.
- Lossless compression — re-packs the same bytes more efficiently. The image is bit-for-bit identical to the original. PNG is lossless. The trade-off is a smaller file size, no quality loss, but the size reduction is more modest (typically 10-30%).
Most "compress my image" requests are for lossy compression (a 5 MB JPEG that should be 500 KB), and the quality-vs-size trade-off is the slider you adjust. For PNG, lossless is the right answer; the original file is already as good as it gets pixel-wise, and re-encoding with a better compressor can save 10-30% without losing anything.
The four major tools, and what each one does well
TinyPNG — the default
TinyPNG is the tool most people have heard of. It uses smart lossy compression (essentially mozJPEG with metadata stripping) and aggressive PNG optimization (essentially oxipng). The free tier allows 20 images per session, each up to 5 MB. The paid tier is $7/month for unlimited images, batch upload, and an API.
Where it wins: the smartest defaults. You upload a JPEG and TinyPNG picks the right quality slider for you, almost always. The visual quality at the default compression level is better than most naive compressors — it knows which patterns the eye will not see. The API is well-documented for batch processing.
Where it loses: 20 images per session in the free tier is restrictive for any real workflow. The upload step is the privacy trade-off — your image goes to TinyPNG's servers, gets compressed, and the compressed version comes back. The metadata stripping is also privacy-positive (no EXIF GPS data) but also means you lose the original metadata if you wanted to keep it.
Squoosh — the open-source one
Squoosh is Google's open-source image compressor, runs in the browser, and was created by the Chrome team. The interface is famous for its side-by-side comparison: original on the left, compressed on the right, with a quality slider on each format's settings. The hosted version at squoosh.app is free for individual use.
Where it wins: the comparison UI is the best in class — you can see exactly what the trade-off is before you commit. The advanced settings (chroma subsampling, color quantization, dithering) let you tune the output to within 1% of the optimal size. The PWA is installable; you can use it offline.
Where it loses: batch processing is limited (one image at a time, or the PWA's "batch" tab which is slow). Google's investment in Squoosh has slowed — the GitHub repo gets sporadic maintenance. The format support is narrower than some competitors (good for JPEG / PNG / WebP, weak for AVIF).
Compressor.io — the polished one
Compressor.io is a paid cloud service (no free tier, $9/month for individuals) with what is arguably the cleanest UI of the bunch. It supports JPEG, PNG, SVG, GIF, and WebP. The lossless and lossy modes are well differentiated; the API is solid.
Where it wins: the lossless PNG compression is the best of the cloud services, and the WebP support is the deepest. The team behind it is responsive and ships improvements. The privacy policy is clear and the EU hosting option is real.
Where it loses: no free tier at all, even for one-off use. The price is comparable to TinyPNG but the brand is smaller, so it is harder to justify to a client or team.
Uttir (and similar in-browser compressors) — the privacy-first one
The in-browser tier is a new wave of compressors that do all the work in the browser. Uttir's image compressor and image compressor to size use the same mozJPEG and libwebp backends as TinyPNG, but the image never leaves your device. The trade-off is convenience: no cloud sync, no shared collections, no API for batch processing.
Where it wins: privacy is the default. The image stays on your device; the compressed result is generated locally. The same is true of Compress-or-Die, browser-image-compression (the npm package), and a handful of others. The compression quality is competitive with the cloud services for individual images.
Where it loses: batch processing is limited to what your browser can hold — a few hundred images at once is fine, a few thousand will run out of memory. No team features, no cloud sync, no API. The advanced settings are not as deep as Squoosh's (no chroma subsampling control, no color quantization options).
What the privacy trade-off actually means
When you upload an image to TinyPNG or Squoosh's hosted version, your image goes from your browser to their server, gets compressed, and comes back. That is the trade-off. For most images, this is fine — your holiday photos, your product shots, your blog illustrations are not sensitive.
For some images, it is not:
- Medical images (X-rays, scans, anything with PHI).
- Financial documents (bank statements, invoices with personal information).
- Screenshots of internal tools (customer data, internal URLs, anything that should not be public).
- Source assets for a product launch (anything you want to keep confidential until launch day).
- Any image that contains an unredacted face or location that the upload service's metadata could be cross-referenced with.
For these cases, an in-browser compressor is the right answer. The image never leaves your device, and there is no third party to trust with the bytes. The performance cost is real (a few seconds instead of instant) but the privacy gain is concrete.
How the compression quality actually compares
Every tool that uses the same backend (mozJPEG, libwebp, oxipng) produces essentially identical output at the same quality setting. The visible difference between TinyPNG and an in-browser compressor using mozJPEG is usually under 1% in file size at the same quality, and zero in visual quality. The tool's "secret sauce" is the smart default — picking the right quality slider for a given input — not the algorithm.
The real difference is the metadata handling. Some compressors strip EXIF (good for privacy, bad if you want to keep the camera info), some preserve it (good for archival, bad for sharing), some let you choose. The compression of color profiles is another variation: most strip them, a few convert sRGB to a more compact profile, and the rest preserve the original.
When to pick which
- One image, no privacy concern: TinyPNG or Squoosh's hosted version. Fast, polished, free.
- One image, privacy concern: in-browser compressor. Same quality, zero upload.
- Batch (10-100 images), no privacy concern: TinyPNG's paid tier or Compressor.io. Batch upload, batch download, polished API.
- Batch (100-10,000 images), any privacy concern: a real image CDN with a build step. Cloudinary, imgix, or Vercel Image Optimization. The cost-per-image is fractions of a cent, the build pipeline integrates with your deploys, and the privacy is the same as the cloud compressor (your images go to a server).
- Highly sensitive images (medical, financial, internal): in-browser, every time. TinyPNG is fast but the upload is a leak. Squoosh's PWA is also private (the PWA runs locally) but the hosted version is not.
The practical answer for most people
For most workflows — blog illustrations, product photos, social media images, casual photography — the difference between TinyPNG and an in-browser compressor is small enough that privacy is the deciding factor. An in-browser compressor wins for the cases where you do not want your images on a third party's server, even briefly. The cloud tools win for batch processing, for advanced format support, and for the times when you want a CDN-backed API.
The two approaches complement each other more than they compete. Most people who care about privacy will use the in-browser tool for the one-off images, and pay for a cloud tool when they have a real batch. The mistake is paying for the cloud tool for everything just because it is the default, when the in-browser tool gives you the same quality output with one fewer company holding your bytes.