Measured, not promised
How much do images actually compress?
Every compression tool promises “up to 90%”. Nobody shows their working. So here is ours: eleven real files, run through the same pipeline, with the numbers that came out — including the two that failed and the one that lost something.
The run
Default settings: automatic format, quality 80, longest edge 1600 pixels. The same code that runs in your browser tab, run against real files rather than samples chosen to look good.
| File | In | Before | After | Saved | Out | Time | Note |
|---|---|---|---|---|---|---|---|
| A 3200×2400 photo | JPEG | 2.9 MB | 264 KB | 91.0% | JPEG | 122 ms | |
| A logo with transparency | PNG | 589 KB | 26 KB | 95.5% | WebP | 135 ms | transparency kept |
| A CMYK print photo | JPEG | 5.7 MB | 243 KB | 95.8% | JPEG | 353 ms | converted to sRGB |
| A 6400×4800 screenshot | PNG | 11.4 MB | 413 KB | 96.5% | JPEG | 142 ms | |
| An 18 MB camera file | JPEG | 18.4 MB | 412 KB | 97.8% | JPEG | 200 ms | |
| An iPhone photo | HEIC | 1.6 MB | 221 KB | 86.5% | JPEG | 391 ms | Display P3, portrait |
| A larger iPhone photo | HEIC | 10.5 MB | 264 KB | 97.5% | JPEG | 1128 ms | |
| A 43 MB HEIC | HEIC | 43.5 MB | 413 KB | 99.1% | JPEG | 8288 ms | 117 MB in memory |
| An animated GIF | GIF | 1.8 MB | 28 KB | 98.4% | JPEG | 12 ms | 16 frames → 1 |
| A truncated JPEG | JPEG | 39 KB | — | — | — | 3 ms | refused: could not decode |
| An empty file | JPEG | 0 B | — | — | — | 1 ms | refused: 0 bytes |
Nine files: 96.2 MB became 2.2 MB — 97.7% smaller — in 10.8 seconds of processing. Two files were refused, on purpose.
Four things the averages hide
Most of the saving is resolution, not quality
The 43 MB HEIC lost 99.1% of its size, but almost none of that is a quality trade. It was 6400 pixels wide and came out 1600 — the same picture, at a size anything will actually display. The photo that gained least (86.5%) was already close to a sensible size. If you are wondering why your results differ from someone else’s, this is usually why.
Forcing one output format is what breaks things
The transparent logo came out as WebP and kept its alpha channel. Had it been forced to JPEG — which has no transparency — the transparent parts would have turned white, and it would have looked like a bug rather than a setting. Compressing images in Google Drive covers when to pick a format yourself and when to let it decide.
HEIC is slow, and it is not the network
The 43 MB HEIC took 8.3 seconds while an 18 MB JPEG took 0.2. No browser decodes HEVC, so a HEIC file goes through a separate decoder — and a 6400×4800 image needs 117 MB of raw pixels in memory before anything is written. That is the real cost of converting iPhone photos, and it is why large batches of them take longer than the file sizes suggest.
What gets lost is worth saying out loud
The animated GIF became a single frame. That is a genuine loss, not a rounding error, and a tool that does not tell you is hiding something. The truncated file and the empty file were both refused rather than written — quietly writing a corrupt result over an original is the one failure that cannot be undone.
What this means for a Drive full of photos
Phone photos are the best case: they are large, over-resolved for screens, and there are a lot of them. If your 15 GB is mostly camera files, the numbers above are roughly what to expect — which is why what actually frees up Drive storage starts with images before anything else.
Questions
How much smaller does compressing an image actually make it?
Across the nine files that compressed, between 86% and 99% — but the range is the interesting part. A photo that is already small and already JPEG gained the least (86.5%). A 43 MB HEIC straight off a phone gained the most (99.1%). Most of that gain is resolution, not quality: a 6400-pixel-wide photo does not need to be 6400 pixels wide to be looked at.
Does compressing a PNG destroy its transparency?
It should not, and here it did not. The transparent logo came out as WebP with its alpha channel intact, 95.5% smaller. Forcing every file to JPEG is what destroys transparency — JPEG has no alpha channel, so the transparent parts turn white.
Why did the animated GIF lose its animation?
Browser image decoding hands back one frame, so a 16-frame GIF becomes a single still. That is a real loss and it is reported rather than hidden. If the animation matters, do not compress the GIF.
What happens to a file that is broken?
Nothing gets written. The truncated JPEG and the 0-byte file were both refused in under 5 ms with a specific reason. A compressor that silently writes a corrupt result over your original is worse than one that refuses.
How were these measured?
The production image pipeline was run against real files in a headless Chrome, at the app’s default settings: automatic format, quality 80, longest edge 1600 pixels. Measured 17 September 2026. The same code runs in your browser tab.