Image compression basics: JPEG, PNG, WebP, and AVIF explained

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 throws away information it assumes your eye won't miss, using a mathematical transform that groups pixels into 8x8 blocks. This works beautifully for photos with soft gradients and poorly for flat colors or sharp text edges, where you start to see blocky artifacts around high-contrast boundaries.

PNG: the 3.1MB outlier

The same image as a lossless PNG came out to 3.1MB — over thirty times larger. PNG is the right choice when you need pixel-perfect fidelity or transparency (screenshots, logos, icons, diagrams with sharp edges and flat colors), but it is the wrong choice for photographs, full stop.

WebP: 61KB, and it handles both cases

WebP compressed the same photo to 61KB at a 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 today unless there's a specific reason not to.

AVIF: 43KB, at a real cost

AVIF got the smallest file at 43KB, roughly half the JPEG's size at similar quality, using compression technology 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.

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, and a JPEG fallback for the rare older browser or tool that doesn't support either. For screenshots, logos, and anything with flat colors or transparency: PNG, or WebP in lossless mode if file 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 the 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 on the page is wasting five times the necessary data regardless of format. Resize first, compress second — that order matters more than which format you land on.

What happened when I batch-tested 200 product photos

For an e-commerce catalog with 200 near-identical white-background product 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 zero visible difference on a full-resolution monitor in a side-by-side comparison. The one gotcha: three images with fine fabric texture patterns needed quality bumped to 90 individually, because the default setting introduced faint banding across the weave that was visible on close inspection, a reminder that a single blanket setting rarely fits every image in a large batch perfectly.

Lossless versus lossy modes inside the same format

Both WebP and AVIF support a lossless mode in addition to 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 around 20% smaller than the equivalent PNGs in my testing, with pixel-identical output, making it a reasonable PNG replacement for teams that don't need universal legacy support.

HEIC and why it never caught on for the web

Apple's HEIC format compresses similarly to AVIF and has shipped as the default camera format on iPhones since 2017, yet it barely appears on the web at all. The reason is licensing: HEIC bundles patented HEVC video compression technology, which means browser vendors would owe royalties to decode it natively, and most non-Apple browsers simply never added support. Any photo you export from an iPhone as HEIC needs converting to JPEG or WebP before it'll display reliably across every browser, which is why so many image tools include a dedicated HEIC-to-JPEG step.

A responsive images mistake that undoes all your compression work

Compressing a single hero image well doesn't help if you're still serving that same 2000-pixel-wide file to a phone with a 380-pixel-wide viewport. The srcset attribute lets you provide multiple resolutions of the same image and let the browser pick the right one for the device, and skipping it is one of the most common reasons a site with perfectly compressed images still scores poorly on mobile page speed tests. On one project, adding a three-size srcset (400w, 800w, 1600w) to a gallery page cut mobile data transfer by 58% with no change to the compression settings themselves.

Batch tooling versus one-off web compressors

For a single image, a browser-based compressor is fine, but for a folder of hundreds, a command-line tool like squoosh-cli or sharp scripted in a small Node script saves enormous time over dragging files one at a time into a web form. The 200-photo catalog job mentioned earlier ran as a ten-line script overnight rather than 200 manual uploads, and produced a consistent, repeatable settings file that the next batch could reuse without re-deciding every quality slider from scratch.

Frequently confused points

Does converting an already-compressed JPEG to WebP save more space? Usually not much, because you're compressing already-lossy data again; re-encode from the original source image 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 — the encoding time cost outweighs the marginal size savings for low-traffic sites.

Why does my compressed image still look blurry? You're likely displaying it at a size larger than its actual pixel dimensions, which no amount of 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 is the sweet spot for most photos — below 70 artifacts become visible, above 90 file size grows fast with little visible quality gain.