I run Convertify, a free image converter built on Rust and libvips. Last week I decided to stop guessing about format performance and actually measure it. I took 50 real images (26 PNGs, 24 iPhone HEIC photos), ran 17 conversions through the production pipeline, and recorded every file size and encode time.
Some results confirmed what everyone says. Others did not.
The three results that surprised me
1. Converting HEIC to JPG makes files 14% bigger, not smaller.
This one hurt. "Convert iPhone photos to JPG" is probably the most common advice on the internet. But HEIC wraps the HEVC codec, which compresses roughly 2x better than JPEG. Going from a better codec to a worse one means the file grows. Every time.
If you actually want smaller iPhone photos: HEIC to WebP saves 43%, HEIC to AVIF saves 57%.
2. AVIF encodes 7x slower than WebP for 10% more compression.
AVIF Q63: 55 KB, 1.30s per image.
WebP Q80: 61 KB, 0.19s per image.
That is a 10% size difference for a 7x speed penalty. For a single hero image, nobody cares. For a batch pipeline processing thousands of product photos, that is the difference between 3 minutes and 21 minutes.
3. PNG at 600 DPI is smaller than PNG at 300 DPI when rasterizing PDFs.
This was the weirdest one. I was benchmarking PDF-to-image and noticed PNG output shrank from 2,221 KB at 300 DPI to 1,660 KB at 600 DPI. I spent an hour convinced I had a bug.
Turns out it is a real property of PNG encoding. Higher DPI renders smoother gradients between adjacent pixels, and PNG's prediction filters (Paeth, sub, up) compress smooth gradients dramatically better than the sharp edges you get at lower resolutions. Not a bug. Just PNG being PNG.
The quick reference table
| Conversion | Size change | Speed |
|---|---|---|
| JPG to WebP Q80 | -64% | 0.19s |
| JPG to AVIF Q63 | -68% | 1.30s |
| PNG to WebP Q80 | -92% | 0.21s |
| PNG to JPG Q85 | -86% | 0.07s |
| HEIC to JPG Q85 | +14% | 1.90s |
| HEIC to WebP Q80 | -43% | 5.64s |
| HEIC to AVIF Q63 | -57% | 14.52s |
| WebP to JPG Q85 | +60% | 0.09s |
| AVIF to JPG Q85 | +80% | 0.15s |
What I actually recommend
For most websites: WebP Q80. 64% smaller than JPG, fast to encode, universal browser support since 2020.
For maximum compression with no time pressure: AVIF Q63. 68% smaller than JPG but 7x slower to encode.
For iPhone photos: Do not convert to JPG. Go straight to WebP or AVIF. JPG is a downgrade in both efficiency and file size.
The full benchmark
The complete data with PDF rasterization benchmarks, DPI comparisons, and methodology is in the full benchmark post on Convertify. Every number was measured on June 18, 2026 on the production Rust + libvips server. No theoretical figures, no borrowed data.
Week 14 of building Convertify in public. Previous posts in the series cover the SSG migration, libvips segfaults, and why I stopped trusting my own landing page copy.
Top comments (8)
Absolutely awesome! Amazing job on the benchmarking, I dont think too many people know exactly what they're trading for when they change formats. Would have been nice if you kept quality settings standardized? Eg. Test for 70%, 80%, 90%. So it shows exactly what the compression is for each tier and show the dropoff.
Good idea, mayby later I will test and this case
The HEIC to JPG one is going to surprise a lot of people, me included. "Convert your iPhone photos to JPG" is everywhere and it quietly makes things worse. The AVIF number is the one I'd act on though. For a batch of product shots, 7x encode time to shave 10% off the size is a bad trade, but for a single hero image nobody will ever notice. Did you test AVIF at a lower effort setting? libvips lets you trade encode speed for compression, and I've always wondered if a faster effort closes most of that gap with WebP.
Interests point, later I Will test this.
This is actually super useful data tbh.
A lot of ppl still blindly convert HEIC - JPG without realizing it’s actually going backwards
also for stuff like this, Pingdom, and GTmetrix can be helpful on the way, sometimes helps to sanity check decisions before shipping.
Nice benchmark work, more of this is needed in real-world setups
Thank you!
Interesting 🤔
yes😅