DigImg vs TinyPNG vs ShortPixel: Size and SSIM

DEV Community

I measured DigImg vs TinyPNG vs ShortPixel on the same images (bytes + SSIM)

A smaller image file is useful. A smaller file that visibly damages a logo, screenshot, or photo is not always a win. So instead of comparing marketing claims, I ran the same four source images through DigImg, TinyPNG, and ShortPixel. I downloaded each result, measured the actual output bytes, and calculated SSIM with the same scikit-image workflow used for DigImg's own measurements. This is a small, reproducible spot check — not a universal ranking of image compressors. The goal is to show the trade-offs on four different image types. Why measure bytes and quality together A compression number on its own is easy to flatter. "Up to 80% smaller" can be true for one photo at one aggressive setting and misleading for everything else. File size tells you what you save; a quality metric tells you what you paid for it. Reporting only one of the two lets a tool look better than it is. That is why every lossy result below carries both an exact byte count and an SSIM score, and every lossless result is labelled pixel-exact. The point is not to crown a winner. It is to make the trade-off visible so you can choose for your own image. The test setup Four identical source images: a photo, a transparent logo, a flat graphic, and a UI screenshot. The downloaded files were measured by actual file size, not a UI estimate. Quality was compared using SSIM under the same scikit-image measurement approach. TinyPNG and ShortPixel were tested through their web interfaces. ShortPixel used the web Lossy/SmartCompress path. This is not an API-to-API benchmark. Different compression modes and settings can change the result. SSIM (structural similarity) compares the decoded output against the source on a 0–1 scale, where 1 means identical structure. I decoded each downloaded file and ran the same calculation DigImg uses internally, so the numbers are comparable across tools. SSIM is a useful proxy, not a substitute for looking at the image — a high score does not guarantee every detail survives, which is why the lossless/lossy label matters as much as the score. Results: the same four inputs Source image DigImg result TinyPNG result ShortPixel result What the test shows Photo, 73.5 KB source JPEG 32.5 KB, SSIM 0.980; WebP 19.1 KB, SSIM 0.974 JPEG 52.1 KB, SSIM 0.988 JPEG 45.5 KB, SSIM 0.978 DigImg produced the smallest JPEG in this run. Its WebP was smaller still, with a lower SSIM than the JPEG outputs. TinyPNG's JPEG scored the highest SSIM. Transparent logo PNG 2.66 KB, lossless / pixel-exact PNG 2.63 KB, lossless / pixel-exact PNG 2.66 KB, lossless / pixel-exact Effectively a tie. All three outputs were pixel-exact for this input. Flat graphic PNG 2.69 KB, lossless / pixel-exact PNG 2.80 KB, lossless / pixel-exact PNG 2.69 KB, lossless / pixel-exact DigImg and ShortPixel tied on bytes; both were slightly smaller than TinyPNG in this run. UI screenshot PNG 1.70 KB, lossless / pixel-exact PNG 2.82 KB, lossless / pixel-exact PNG 1.38 KB, SSIM 0.9957 (lossy) ShortPixel made the smallest file, but it was lossy. DigImg's output was the smallest lossless option in this run. What I would take away 1. There is no single winner across every image type For the photo, DigImg's JPEG was smaller than the JPEG outputs from TinyPNG and ShortPixel in this run. TinyPNG retained the highest SSIM score among those JPEG results. DigImg's WebP was smaller than all three JPEG files, but it is a different output format and had a lower SSIM score than the JPEG results. For the transparent logo, the three tools were effectively tied. For the flat graphic, DigImg and ShortPixel tied. For the screenshot, ShortPixel produced the smallest file, while DigImg produced the smallest pixel-exact lossless PNG. That is why a useful comparison should show both size and quality — and should say when a smaller output is lossy. 2. "Lossless" is a practical choice, not just a checkbox For logos, diagrams, and screenshots, preserving exact pixels can matter more than shaving off another f...

Powered by Readybot.io