The most common marketing line from compression tools is something like “reduce file size by 70%” — an unverifiable figure. This article cites no industry statistics. It presents only a real benchmark, with a complete comparison method that anyone can reproduce.
1. Test Subject: Not Original Images, but Images Already Compressed Once
Most compression tests use pristine camera-original images — ideal conditions that rarely match real usage. This test deliberately mimics a real business scenario: a website that lets users upload images has already run a standard compression pass before storing them. In other words, the test files are not untouched source images, but finished images that have already been “compressed once.”
Sample size: 78 folders with 4,624 images (mainly JPG). The directory structure follows the typical “one album per folder” archive layout, with no filtering or cleanup applied.
The total size of these files on the server: 1.41 GB.
Core question: How much more space can be squeezed out when an image that has already been processed by one compression tool is handed to another? Most users assume “once compressed, it's done — no point compressing again.”
2. Control Group: How Much Can Zip Compression Save?
Before running ImgZilla, the same set of files was packed into a zip archive as-is to see what a general-purpose compression algorithm could achieve:
| Size | vs. Original | |
|---|---|---|
| Site-compressed original files | 1.41 GB | — |
| Zipped into archive | 1.41 GB | -0.2% |
Almost no change. The reason isn't complicated: JPEG is already a compressed format. The image data has already gone through entropy coding, and a general-purpose algorithm (zip uses DEFLATE) can hardly compress pre-compressed data further — regardless of whether the originals had been processed by the website, zip can do little here.
3. Recompression Test with ImgZilla
Drag the files above into ImgZilla and compress them in place. With 78 folders and 4,624 images, file names and directory structure are fully preserved:
| Size | vs. Original | |
|---|---|---|
| Site-compressed original files | 1.41 GB | — |
| Zipped into archive | 1.41 GB | -0.2% |
| After ImgZilla recompression | 0.75 GB | -46.8% |
On top of the website's own compression, ImgZilla saved another ~662 MB, nearly halving the total size. All folder paths, file names, and hierarchy remained exactly the same — this is verifiable real data, not marketing talk.
This reveals a key fact: “compressed at upload time by the website” and “finely encoded with format-specific parameters” are two different things. Most websites apply a one-shot, conservative pass at ingest — usually only limiting a quality parameter or dimensions — far from exhausting the encoding headroom of each format. ImgZilla tunes parameters per format and performs visually lossless re-encoding for JPEG: changes do exist at the pixel level, but parameters are set in a range that is nearly imperceptible to the human eye, allowing further space to be found on top of an already-compressed file.
One point worth clarifying: “visually lossless” is not the same as “lossless”. Truly lossless (pixel-identical output) applies only to PNG (oxipng) and SVG; JPEG, WebP, AVIF, HEIC, and GIF are, by nature, lossy re-encoding, except the compression parameters are kept within a visually lossless threshold. ImgZilla includes a built-in comparison window with a left/right split view before and after compression, and can zoom to actual size for pixel-by-pixel comparison, so you can verify it yourself.
4. Detailed Analysis: Per-File Compression Ratio, Pixel Dimensions, and Processing Time
The 46.8% overall reduction above is the aggregate result across 4,624 images. Breaking it down to individual files reveals more detail.
Per-Image Compression Ratio Distribution Is Uneven
For each image, the compression ratio was calculated as the share of bytes saved; the values ranged from 32.3% to 85.8%:
- Highest-compression-ratio batch: ~765 KB compressed to 109 KB, a 85.8% reduction — these are typically images that had not been aggressively compressed initially, leaving significant room for re-encoding.
- Lowest-compression-ratio batch: ~572 KB compressed to 387 KB, a 32.3% reduction — these images had already been squeezed hard before, so there was little headroom left.
- The arithmetic mean compression ratio across all 4,624 images is 46.44%, close to but not exactly the same as the overall 46.8% calculated from total volume. The former is a simple average of individual compression ratios; the latter is “total bytes saved ÷ total original bytes.” The difference means that files with high and low compression ratios do not carry equal weight in the total volume; a few large files have a larger impact on the overall result.
Notably, every image showed a positive compression ratio, and none was skipped as “already minimal.” In other words, among these website-compressed images, every single one yielded real additional savings under ImgZilla.
Pixel Dimensions: Exactly Identical
Counting the pixel dimensions of all 4,624 images, the most common sizes were 1600×2400 (1,756 images) and its landscape counterpart 2400×1600 (500 images). Dimensions ranged from the smallest 450×675 (~0.3 megapixels) to the largest 3000×2000 / 2000×3000 (~6 megapixels).
Sampling and comparing pixel dimensions before and after compression shows they are exactly identical — no change whatsoever:
| File (example) | Original dimensions | Compressed dimensions |
|---|---|---|
| Sample 1 | 1600×1066 | 1600×1066 |
| Sample 2 | 2000×3000 | 2000×3000 |
| Sample 3 | 1416×2128 | 1416×2128 |
This is the other easily overlooked half of the “in-place compression” definition: not only file names and paths stay the same, resolution also stays fixed. ImgZilla does not resize or crop; all size reductions come purely from re-encoding, not from sacrificing pixels.
Processing Time: 4,624 Images in 51m32s, Averaging 0.669s Per Image
Test environment: a Mac mini with an Apple M1 chip and 8 GB of unified memory; images were stored on a NAS hard drive connected over a 2.5G wired network.
Task progress was tracked using each image's last-write time — when ImgZilla finished compressing the image and wrote it back to disk: the first file was written at 16:06:09 and the last at 16:57:41, for a total batch processing time of 51 minutes 32 seconds, or an average of 0.669 seconds per image.
These figures are consistent with the product's serial processing design — images are compressed one after another rather than written in parallel. That translates to about 90 images per minute. Actual speed depends on image size and hardware; the numbers above are only what this batch of ~305 KB average images took in this environment, not a universal benchmark.
5. Why Compress In Place Instead of Saving Copies
If this test had used a tool that saves compressed copies, the result would have been: 1.41 GB of original files + 0.75 GB of compressed files, taking up 2.16 GB in total — more overall space. It would also generate a large number of xxx-min.jpg files, requiring manual organization and updates to references in a database or product table.
ImgZilla works in place: compressed results are written back to the original path, and all 4,624 file names in the 78 folders remain unchanged — especially important for sites that have already stored image paths in a database, CDN, or CMS references. No links need to be modified after compression. The trade-off is that it modifies the original files, so by default ImgZilla first moves the originals to the system trash, then writes the compressed result. If you change your mind, right-click and choose “Put Back” in the trash.
6. Cost-Benefit Analysis: From Real-World Scenarios to Monthly Bills
Who Can Benefit from These Numbers
- Websites / developers with user-uploaded images: Image storage and CDN traffic are usually billed per GB, so halving the size roughly halves the bill. Traffic fees accrue on every access, and the more visits you get, the stronger the compounding effect. Even if routine compression was applied at upload time, this test shows that running a dedicated, tuned compression pass still yields meaningful gains.
- Servers with tight storage / small-disk users: Cleanup tools typically delete caches and duplicate files, but these pile up again after a few months. Space freed by compression, however, comes from the in-use files themselves becoming smaller, so it does not bounce back. Compressing these 78 folders freed 662 MB of usable space immediately, and that space stays free permanently.
- Users who frequently move data: For copies, syncs, and backups, a 46.8% size reduction cuts transfer time by roughly the same proportion. Compress once; every subsequent transfer saves time.
Putting It Into Monthly Bills: How Much Is That 46.8% Worth?
The ultimate proof lies in the bill. Below, instead of citing any statistics such as “compression improves conversion rates,” I simply multiply the 46.8% measured in this test by the public storage/traffic prices of major cloud providers — pure arithmetic.
Storage savings = volume saved (GB) × unit price (CNY or USD / GB / month)
Outbound traffic savings = volume saved (GB) × downloads/visits in the month × unit price (CNY or USD / GB)
When volume is halved, both bills are essentially cut in half too — that's math, not a guess.
Storage Costs: The Bigger the Library, the Bigger the Savings
Chinese providers:
| Original library size | Volume saved | Alibaba Cloud OSS Standard Storage ¥0.09/GB/month |
|---|---|---|
| 10 GB | 4.68 GB | ¥0.42/month |
| 100 GB | 46.8 GB | ¥4.21/month |
| 1 TB | 479 GB | ¥43.1/month |
Overseas providers:
| Original library size | Volume saved | AWS S3 Standard $0.023/GB/month |
Google Cloud Storage $0.020/GB/month (US Regional) |
Azure Blob Storage $0.018/GB/month (Hot, LRS) |
Cloudflare R2 $0.015/GB/month |
|---|---|---|---|---|---|
| 10 GB | 4.68 GB | $0.11/month | $0.09/month | $0.08/month | $0.07/month |
| 100 GB | 46.8 GB | $1.08/month | $0.94/month | $0.84/month | $0.70/month |
| 1 TB | 479 GB | $11.02/month | $9.58/month | $8.62/month | $7.19/month |
The storage prices of the major overseas providers are quite close — within 30% of each other. The key point is not which one is cheaper, but that when you halve the size, this line item is essentially halved too, and it repeats every month. Compress once, and every following month is billed on the new volume; it's a one-time effort with long-term recurring returns.
Traffic Costs: The Real Driver, Amplified by Access Volume
Traffic fees deserve more attention than storage because they are the product of volume × number of downloads — the more frequently images are accessed, the larger the benefit of compression. Assume a 100 GB image library generates 500 GB of egress through a CDN in a month (roughly the equivalent of the entire library being downloaded five times):
| CDN / egress rate (first tier) | Monthly traffic cost before | After compression (traffic also −46.8%) | Monthly savings | Annual savings |
|---|---|---|---|---|
| Alibaba Cloud CDN China (low tier ¥0.15/GB) | ¥75.0 | ¥39.9 | ¥35.1 | ¥421 |
| AWS CloudFront Asia Pacific ($0.12/GB) | $60.0 | $31.9 | $28.1 | $337 |
| Google Cloud CDN North America/Europe ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
| Azure Front Door Standard Zone 1 ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
The above uses each provider's lowest tier; actual tiered pricing is often higher (Alibaba Cloud CDN domestic traffic can reach as high as ¥1.31/GB at the top tier). The larger the bill, the greater the absolute savings from compression. Also note that Azure at this level is currently Front Door Standard, which includes a base service fee of about $35/month in addition to per-GB egress. That base fee cannot be reduced by compression and is not counted in the savings shown above.
Cloudflare R2 is an exception: its egress traffic is $0 — if the bucket uses R2, almost all compression savings appear on the storage line, since there is no traffic bill at all. This is a different cost structure from the “storage + traffic” double-billing architecture (such as Alibaba Cloud OSS+CDN or AWS S3+CloudFront). Know your billing model before choosing a provider.
These unit prices are compiled from public pricing in 2026. Actual prices depend on region, account discounts, and tier levels; please check provider websites for current pricing. Download counts and visits are hypothetical examples — replace them with your own bill data for a realistic estimate.
7. Savings in Transfer and Upload Time
Halving the volume shortens transfer time by roughly the same factor. This principle doesn't depend on cloud bills; it applies to local copies, backups, and user uploads alike.
Local Scenarios: USB 3 and Gigabit Networking
- USB 3 portable HDD: sustained read/write throughput typically 100–150 MB/s; for estimates use the midpoint, 120 MB/s.
- USB 3 portable SSD: considerably faster, typically 400–500 MB/s; use 450 MB/s.
- Gigabit wired network (1000 Mbps): theoretical ceiling of 125 MB/s; after protocol overhead, real-world sustained throughput is about 100–110 MB/s; use 105 MB/s.
The above are estimates drawn from typical measured ranges. Real throughput depends on the storage medium, interface quality, and network environment; use them only as rough figures.
| Scenario | Volume saved | USB 3 HDD @120 MB/s | USB 3 SSD @450 MB/s | Gigabit network @105 MB/s |
|---|---|---|---|---|
| This test batch | 662 MB | ≈5.5 s | ≈1.5 s | ≈6.3 s |
| 10 GB library | 4.68 GB | ≈40 s | ≈10 s | ≈45 s |
| 100 GB library | 46.8 GB | ≈6.5 min | ≈1.7 min | ≈7.4 min |
| 1 TB library | 479 GB | ≈66 min | ≈18 min | ≈76 min |
The 662 MB in this test may seem small for a single operation — just a few seconds. But as with storage fees, this is a one-time effort with ongoing recurring payoff: whether you are copying to or from an external drive, syncing a NAS, running Time Machine, migrating to a new Mac, or sending files to a colleague, every time you move this data you save time by the same proportion. Compress once, and every future transfer is faster.
If Compression Happens Before Users Upload: Reducing Wait Time
What was calculated above covers benefits after the images are stored — storage fees, CDN egress fees, local transfer. One more link deserves attention: the wait time from when a user presses “Upload” until the progress bar completes. That transfer runs over the user's own upload bandwidth, which is usually the slowest bottleneck in the chain — typical consumer broadband upload speed is only one-tenth to one-fifth of download speed, and mobile networks are even worse. If a website or app compresses images with ImgZilla before the user uploads, the bytes saved translate directly into less waiting time for the user.
Using the average per-image volume from this test: the website's already-compressed images averaged 299 KB; after ImgZilla they averaged 159 KB, saving roughly 140 KB per image.
| Upload bandwidth (typical ranges from public speed-test data, for reference) | Single image 299KB→159KB |
Upload a 50-image album ≈15.0MB→8.0MB |
Upload all 4,624 images from this test 1.41GB→0.75GB |
|---|---|---|---|
| Mobile (combined 4G/5G; China public median 10–50 Mbps, use 30 Mbps) | saves ≈0.04 s | saves ≈1.9 s | saves ≈3 min |
| Typical home broadband upload (100M/1000M download plans with limited upload, ~20–30 Mbps, use 25 Mbps) | saves ≈0.04 s | saves ≈2.2 s | saves ≈3.5 min |
| Gigabit symmetric upload (a few providers/enterprise leased lines, 1000 Mbps) | saves ≈0.001 s | saves ≈0.06 s | saves ≈5.3 s |
| International reference: US average fixed-broadband upload (Ookla data, 2026) | saves ≈0.02 s | saves ≈1 s | saves ≈1.5 min |
Looking at this table for a single image may seem pointless — 0.04 seconds is imperceptible. That is an honest result: this test set was not large to begin with (images had already been compressed by the website before upload, averaging only 299 KB each). There are two scenarios where the value really shows: batch uploads of an entire album or dozens of images at once, and original assets that are much larger (camera-original JPEGs or UGC being uploaded for the first time without any website compression; a single image is often several MB, not a few hundred KB). Under the same compression ratio, the absolute number of seconds saved scales up accordingly. Mobile users, whose upload bandwidth is already slower, will notice the shorter wait even more.
The mobile and home broadband range figures are based on public speed-test statistics from China (4G/5G medians and typical broadband upload ratios). Actual speeds vary considerably with carrier, location, device, and network congestion, so treat these as order-of-magnitude estimates. The US fixed-broadband upload figure is based on data from Ookla Speedtest reports.
Want to verify it yourself? Simply download ImgZilla from the Mac App Store and run it on a few images already processed by your own website before deciding whether to compress the rest.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Learn more: https://imagetool.app/ImgZilla