What we measured, in one paragraph
On 2026-10-16 we ran all 24 combinations (8 images × 3 targets) through CrunchyPic’s exact-size compressor in Chromium on Linux, keeping the page default of JPEG output and the page-default target for each URL. For every run we recorded the exact output file size in bytes, the “You saved X%” figure, the quality percentage the engine settled on, the output dimensions, and an approximate elapsed time. The raw table is below — no cherry-picking, including the runs where “compression” made files larger.
The test set: 8 real images
All eight are verified public-domain or CC0 files from Wikimedia Commons, so anyone can re-download the exact originals and repeat this test. License for each file was verified per-file via the Commons API on 2026-10-16.
| ID | Image | Type | Format | Dimensions | Original size | License |
|---|---|---|---|---|---|---|
| T01 | Landscape photo | Landscape photo | JPEG | 2048×1536 | 542,714 B (530 KB) | Public domain |
| T02 | Portrait photo | Portrait photo | JPEG | 4000×5051 | 6,644,579 B (6.34 MB) | Public domain |
| T03 | Object / still-life photo | Object photo | JPEG | 2000×1588 | 375,265 B (366 KB) | Public domain |
| T04 | Software screenshot | Screenshot | PNG | 793×607 | 172,859 B (169 KB) | Public domain |
| T05 | Orbit diagram | Diagram / graphic | PNG | 1954×1440 | 111,376 B (109 KB) | Public domain |
| T06 | Wide logo | Logo | PNG | 4942×780 | 52,706 B (51 KB) | Public domain |
| T07 | Painting scan | Painting | JPEG | 1996×1455 | 338,837 B (331 KB) | Public domain |
| T08 | Transparent icon | Icon (transparency) | PNG | 512×512 | 14,227 B (13.9 KB) | CC0 |
Site stats we measured
Context for the test environment, measured 2026-10-16 by direct fetch of the live site (all HTTP 200):
| Stat | Value | Method |
|---|---|---|
| Distinct tool pages linked from homepage | 49 | Counted single-segment internal paths on crunchypic.com (54 found; excluded /about/, /contact/, /privacy/, /terms/, /guides/) |
| Tool cards in homepage tools grid | 32 | Counted card anchors in homepage HTML |
| URLs in sitemap.xml | 62 | Counted <loc> entries in sitemap.xml |
| Homepage transfer size | 46,768 bytes | curl download size |
| /compress-image-to-2mb/ transfer size | 49,116 bytes | curl download size |
How the compressor works (documented, not asserted)
We read the engine mechanics from the live page source so every claim about “how it works” is verifiable:
- 100% client-side: draws the image to
<canvas>and encodes withcanvas.toBlob(mime, quality). No upload, ever. - Target-size algorithm: binary-searches JPEG/WebP quality from 0.9 down to 0.1 over 12 iterations to land at or under the target byte count.
- Downscaling is the last resort: if still over target after the quality search, dimensions shrink by ×0.9 and the search repeats; the short side never goes below 320 px.
- PNG mode: no quality parameter (lossless canvas PNG) — only downscaling reduces size.
- Size presets (bytes): 20KB=20480, 50KB=51200, 100KB=102400, 200KB=204800, 500KB=512000, 1MB=1048576, 2MB=2097152.
- Format options in the UI: JPEG (default, “best for photos”), WebP (“smallest file”), PNG (“best for graphics”).
- Result UI shows: “You saved X%!”, original → compressed sizes, quality % used, output dimensions; the download link yields the exact output file.
- Max input: 100 MB (browser reliability guard).
The results: all 24 runs
Format JPEG (page default) on every run; page-default targets untouched. “Output bytes” is the exact size of the downloaded output file. “Saved %”, “Quality” and “Output dims” are as shown in the tool’s result UI. Times are approximate.
| Image | Target | Output bytes | Saved | Quality | Output dims | ≈ sec | Notes |
|---|---|---|---|---|---|---|---|
| T01 landscape (530 KB) | 2MB | 572,486 | 0% | 90% | 2048×1536 | 3–4 | Already under target; re-encoded at Q90, grew slightly |
| T01 | 500KB | 508,644 | 6% | 85% | 2048×1536 | ≈5 | |
| T01 | 100KB | 98,378 | 82% | 15% | 2048×1536 | 3–4 | |
| T02 portrait (6.34 MB) | 2MB | 2,075,531 | 69% | 79% | 4000×5051 | ≈20 | |
| T02 | 500KB | 492,490 | 93% | 32% | 4000×5051 | ≈23 | |
| T02 | 100KB | 98,950 | 99% | 10% | 2916×3682 | ≈90 | Quality hit 10% floor, then engine downscaled 4000×5051→3600×4546→3240×4091→2916×3682 |
| T03 object (366 KB) | 2MB | 443,706 | 0% | 90% | 2000×1588 | ≈5 | Already under target; GREW (re-encode at Q90) |
| T03 | 500KB | 443,706 | 0% | 90% | 2000×1588 | ≈5 | Same as 2MB run |
| T03 | 100KB | 95,204 | 75% | 24% | 2000×1588 | ≈2 | |
| T04 screenshot (169 KB) | 2MB | 176,380 | 0% | 90% | 793×607 | ≈2 | Already under target; grew slightly |
| T04 | 500KB | 176,380 | 0% | 90% | 793×607 | ≈2 | Same as 2MB run |
| T04 | 100KB | 101,861 | 41% | 60% | 793×607 | ≈3 | |
| T05 diagram (109 KB) | 2MB | 161,857 | 0% | 90% | 1954×1440 | ≈4 | Already under target; GREW 109→158 KB |
| T05 | 500KB | 161,857 | 0% | 90% | 1954×1440 | ≈3 | Same as 2MB run |
| T05 | 100KB | 100,999 | 9% | 60% | 1954×1440 | ≈3 | |
| T06 logo (51 KB) | 2MB | 72,213 | 0% | 90% | 4942×780 | ≈5 | Already under target; GREW 51.5→70.5 KB |
| T06 | 500KB | 72,213 | 0% | 90% | 4942×780 | ≈5 | Same as 2MB run |
| T06 | 100KB | 72,213 | 0% | 90% | 4942×780 | ≈5 | Already under target at every level |
| T07 painting (331 KB) | 2MB | 409,504 | 0% | 90% | 1996×1455 | ≈6 | Already under target; GREW 331→400 KB |
| T07 | 500KB | 409,504 | 0% | 90% | 1996×1455 | ≈5 | Same as 2MB run |
| T07 | 100KB | 98,331 | 71% | 23% | 1996×1455 | ≈3 | |
| T08 icon (13.9 KB) | 2MB | 10,025 | 30% | 90% | 512×512 | ≈3 | Only under-target image that SHRANK |
| T08 | 500KB | 10,025 | 30% | 90% | 512×512 | ≈2 | Same as 2MB run |
| T08 | 100KB | 10,025 | 30% | 90% | 512×512 | ≈2 | Already under target at every level |
Key findings
- Under-target images are still re-encoded at JPEG quality 90% — and usually get bigger: T03 366→434 KB, T05 109→158 KB, T06 51.5→70.5 KB, T07 331→400 KB, T04 169→172 KB, T01 530→559 KB. The “You saved” figure floors at 0% — it never goes negative, so the UI won’t tell you the file grew.
- Only T08 (a small flat-color icon PNG) shrank while already under target (13.9→9.8 KB, 30% saved). Flat graphics with few colors are the exception.
- Dimensions shrink only as a last resort. Quality drops to the 10% floor first; only then does the engine downscale. We observed this exactly once: T02 at the 100KB target, 4000×5051 → 2916×3682 over three ×0.9 steps (taking ~90 seconds).
- No errors, CAPTCHAs, or sign-in walls on any of the 24 runs. One UI quirk noted: after “Compress another” plus a new upload, the preview briefly shows the previous run’s data until the new compression completes.
Methodology: reproduce this yourself
- Record the date, browser, and machine of your run — results vary slightly by browser canvas encoder.
- For each test image (re-download the exact originals from the Wikimedia source links in the test-set table above):
- Open the target page: compress-image-to-2mb (target 2MB), compress-image-to-500kb (target 500KB), compress-image-to-100kb (target 100KB).
- Keep format = JPEG (default). Do not change the target — the page default matches the URL’s target.
- Upload the test image via the dropzone. Start a stopwatch when clicking “Compress”.
- When done, record: the “You saved X%!” figure, the “original → compressed” sizes, the quality % shown, the output dimensions shown, and stopwatch seconds.
- Download the output file and record its exact byte size (this is the authoritative output size).
- Click “Compress another” and repeat.
- Do not cherry-pick: run all 24 combinations, including images already smaller than the target — the engine re-encodes them, and that behavior is itself a finding.
- Publish the raw table alongside any summary so readers can verify.
Limitations — read before citing
- Browser-dependent: all runs used Chromium on Linux. Other browsers’ canvas JPEG encoders produce slightly different byte counts at the same quality setting — the pattern holds, the exact bytes shift.
- Times are approximate (stopwatch, single runs) — treat them as order-of-magnitude, not benchmarks.
- JPEG output only. WebP and PNG modes were not part of this run set; PNG mode in particular behaves differently (lossless — only downscaling reduces size).
- Eight images is a test set, not the universe. It covers photos, screenshots, graphics and an icon, but your images will differ — which is exactly why the tool shows you the before/after numbers for your own files.
- Single run per combination. No repeat runs, so we report no variance statistics.
Data recorded 2026-10-16. Test images: public domain / CC0 via Wikimedia Commons (links above).