Forge Notes
Web & Performance5 min readNovember 15, 2026

I tested DigImg against TinyPNG and ShortPixel on the same four images ​

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 imageDigImg resultTinyPNG resultShortPixel resultWhat the test shows
Photo, 73.5 KB sourceJPEG 32.5 KB, SSIM 0.980; WebP 19.1 KB, SSIM 0.974JPEG 52.1 KB, SSIM 0.988JPEG 45.5 KB, SSIM 0.978DigImg 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 logoPNG 2.66 KB, lossless / pixel-exactPNG 2.63 KB, lossless / pixel-exactPNG 2.66 KB, lossless / pixel-exactEffectively a tie. All three outputs were pixel-exact for this input.
Flat graphicPNG 2.69 KB, lossless / pixel-exactPNG 2.80 KB, lossless / pixel-exactPNG 2.69 KB, lossless / pixel-exactDigImg and ShortPixel tied on bytes; both were slightly smaller than TinyPNG in this run.
UI screenshotPNG 1.70 KB, lossless / pixel-exactPNG 2.82 KB, lossless / pixel-exactPNG 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 few hundred bytes. In this test, all three tools produced pixel-exact outputs for the logo and flat graphic. The screenshot results show the trade-off more clearly: ShortPixel's output was smaller, while DigImg retained exact pixels. If the screenshot contains text or sharp edges that a client will zoom into, the few hundred bytes are rarely worth a lossy pass.

3. Local processing is a trust property, but not a category-exclusive claim ​

DigImg processes images in the browser, and the project team reports that network capture verified no user-image upload during the tested workflow. That matters for client assets, unpublished product images, and private screenshots.

But it would be inaccurate to say that every competing browser tool uploads images. Squoosh is also known for browser-local processing. The stronger product question is whether a user can complete a practical batch workflow, compare formats, choose a target size, and verify the result without sending image files to a remote service.

4. A benchmark is only as useful as its disclosure ​

Four images are enough to demonstrate concrete examples, not enough to claim a universal 38% advantage or declare one compressor the best. The defaults, image content, output format, metadata handling, and quality setting all affect the result.

Method limitations ​

Read these numbers as a spot check, not a verdict. There were four inputs and one run per tool, through the web interfaces rather than the APIs, at each tool's default or smart setting. A different photo, a different quality knob, or an API call with explicit parameters could reorder the results. SSIM is a structural proxy and does not replace human visual review, especially for text and fine edges. Nothing here measures speed, memory use, or batch throughput. Treat the table as a worked example of how to compare — then run your own image through the tools before you decide.

Try the workflow ​

DigImg is built for browser-local image optimization with format comparison, batch processing, and target-size workflows. The comparison page includes the measured results and the test boundaries.

The goal is not to tell you that one tool wins every time. It is to make the decision visible: how small did the file get, what happened to quality, and did the image need to leave your device?

Related Notes