JPEG vs WebP vs AVIF vs PNG: Real File Size Comparison

The test photo

I ran the same 4000x3000 photo of a cluttered desk, a mix of sharp text, soft shadows, and a gradient window reflection, through four formats at comparable visual quality, and the size differences were large enough to matter for anyone shipping images on the web.

JPEG: the 88KB baseline

Saved at quality 80, the JPEG came out to 88KB. JPEG discards information it assumes the eye won't miss, using a transform that groups pixels into 8x8 blocks. That works well for soft photographic gradients and poorly for flat colors or sharp text edges, where blocky artifacts appear around high-contrast boundaries.

PNG: the 3.1MB outlier

The same image as lossless PNG came out to 3.1MB, over thirty times larger. PNG is the right pick when pixel-perfect fidelity or transparency matters, screenshots, logos, icons, diagrams, but it's the wrong choice for photographs, full stop.

WebP: 61KB, and it covers both use cases

WebP compressed the same photo to 61KB at visually matching quality, about 30% smaller than the JPEG, while also supporting transparency like PNG when needed. Browser support has been effectively universal since 2021, which is why most image pipelines default to WebP unless there's a specific reason not to.

AVIF: 43KB, at a real cost

AVIF produced the smallest file at 43KB, roughly half the JPEG's size at similar quality, using compression borrowed from video codecs. The catch is encoding time: the AVIF took about eleven times longer to encode than the WebP in the same batch job, which matters if you're compressing thousands of images on a build server rather than one photo by hand.

Side-by-side numbers

PNG: 3.1MB, lossless, best for flat graphics. JPEG: 88KB, universal support, fine for photos. WebP: 61KB, broad support, handles both photos and transparency. AVIF: 43KB, smallest, but slow to encode and occasionally inconsistent on older decoders.

So which one do you actually pick

For photos on a website: WebP as the default, AVIF if you're optimizing aggressively and can tolerate longer build times, with a JPEG fallback for the rare tool or browser that doesn't support either. For screenshots and flat-color graphics: PNG, or lossless WebP if size matters. For anything animated: WebP has mostly replaced GIF at a fraction of the size for the same animation.

The setting that matters more than format choice

Before worrying about format at all, check whether the image is even sized correctly. A 4000-pixel-wide photo displayed at 800 pixels wastes roughly five times the necessary data regardless of format. Resize first, compress second. That order matters more than which format you land on.

A batch test on 200 product photos

For an e-commerce catalog with 200 near-identical white-background shots, converting the existing JPEGs straight to WebP at quality 82 cut the total folder size from 340MB to about 118MB, a 65% reduction, with no visible difference on a full-resolution monitor. The one exception: three images with fine fabric texture needed quality bumped to 90 individually, since the default setting introduced faint banding across the weave, a reminder that a single blanket setting rarely fits every image in a large batch.

Lossless modes inside WebP and AVIF

Both WebP and AVIF support a lossless mode alongside their usual lossy compression, which matters for screenshots and UI mockups where PNG has traditionally been the default. Lossless WebP on a screenshot-heavy folder came in about 20% smaller than equivalent PNGs in my testing, with pixel-identical output, making it a reasonable PNG replacement for teams that don't need universal legacy support.

Why HEIC never caught on for the web

Apple's HEIC format compresses similarly to AVIF and has shipped as the default iPhone camera format since 2017, yet it barely appears on the web. The reason is licensing: HEIC bundles patented video compression technology, so browser vendors would owe royalties to decode it natively, and most non-Apple browsers simply never added support. Any HEIC export needs converting to JPEG or WebP before it displays reliably everywhere.

A responsive images mistake that erases your compression work

Compressing a hero image well doesn't help if you're still serving the same 2000-pixel-wide file to a phone with a 380-pixel-wide viewport. The srcset attribute lets a browser pick the right resolution for the device, and skipping it is one of the most common reasons a site with well-compressed images still scores poorly on mobile speed tests. Adding a three-size srcset to one gallery page cut mobile data transfer by 58% with no change to compression settings at all.

Frequently confused points

Does converting an already-compressed JPEG to WebP save more space? Usually not much, since you're recompressing already-lossy data. Re-encode from the original source when possible for the best result.

Is AVIF worth using for a small personal site? Probably not the effort unless your build pipeline already handles it automatically, since encoding time outweighs marginal savings for low-traffic sites.

Why does my compressed image still look blurry? You're likely displaying it larger than its actual pixel dimensions, which no compression setting can fix. Check the rendered width against the source resolution.

What quality setting should I use for JPEG? Somewhere between 75 and 85 for most photos; below 70 artifacts become visible, above 90 file size grows fast with little visible gain.