JPG vs WebP vs AVIF: compression formats compared
A practical comparison of the three dominant raster image formats in 2026 - compression ratios, compatibility, and when to use which.
If you care about web performance and you’ve looked at image optimisation recently, you’ve seen three formats mentioned repeatedly: JPG, WebP, and AVIF. All three do essentially the same job — compress photographs — but they occupy very different points on the compatibility/compression trade-off.
Here’s a practical comparison: how they work, how much smaller they actually are, where they’re supported, and when to use each.
At a glance
| Format | Released | File size (photo, same quality) | Browser support | Encoding speed |
|---|---|---|---|---|
| JPG | 1992 | Baseline (100%) | 100% | Fast |
| WebP | 2010 | 65-75% | ~96% | Medium |
| AVIF | 2019 | 40-55% | ~92% | Slow |
JPG wins on compatibility and encoding speed. WebP is the current sweet spot. AVIF produces the smallest files but takes significantly longer to create.
How they work under the hood
JPG
JPG compresses images by dividing them into 8×8 pixel blocks and transforming each block into frequency components using the Discrete Cosine Transform. High-frequency components (fine detail) are quantised aggressively — that’s where the lossy compression happens. The result is reconstructed with a predictable set of artefacts: block boundaries visible at low quality, “ringing” around sharp edges, and blurred fine detail.
The underlying math has been essentially unchanged since the 1990s. The format is simple, universally supported, and fast to encode and decode.
WebP
WebP (Google, 2010) uses block-based prediction derived from the VP8 video codec. Instead of independent 8×8 blocks, each block can reference its neighbours, which is much more efficient for natural images. WebP also supports lossless compression (competitive with PNG), alpha transparency (like PNG), and animation (like GIF, but far smaller).
At the same perceptual quality as a JPG, a WebP file is typically 25-35% smaller. WebP supports quality settings from 0 to 100 like JPG.
AVIF
AVIF (Alliance for Open Media, 2019) is based on the AV1 video codec — the latest generation of open-source compression. It uses more sophisticated techniques: larger and variable-size blocks, more prediction modes, and better entropy coding.
At the same perceptual quality as JPG, an AVIF file is typically 45-55% smaller. AVIF also supports transparency, HDR, wide colour gamuts, and animation.
The catch: encoding AVIF is slow. Creating an AVIF from a photograph can take 2-10× longer than the equivalent WebP, and 10-30× longer than JPG. Decoding is faster but still more work than JPG.
Real-world file size comparison
Typical photograph (4000×3000 px, camera output) encoded at visually equivalent quality:
| Format | File size | vs JPG |
|---|---|---|
| PNG (lossless) | 28 MB | +2400% |
| JPG (quality 85) | 1.2 MB | 100% |
| JPG (quality 75) | 620 KB | 52% |
| WebP (quality 85) | 780 KB | 65% |
| WebP (quality 75) | 380 KB | 32% |
| AVIF (quality 85) | 540 KB | 45% |
| AVIF (quality 75) | 250 KB | 21% |
The savings are dramatic. Going from JPG-85 to AVIF-75 is more than 4× smaller — for a page that loads 10 images, that’s a multi-megabyte difference.
Browser and tool support in 2026
JPG: Universal. Every browser, email client, operating system, document editor, CMS, and image viewer supports it. If a system can display images at all, it can display JPG.
WebP: Supported in all modern browsers (Chrome, Firefox, Safari, Edge, Opera, Samsung Internet) and essentially all major operating systems. WebP is now safe as a primary format for web images. The remaining gaps are in older tooling: some image editors, email clients, and third-party CMSs still handle WebP awkwardly.
AVIF: Supported in Chrome, Firefox, Safari, Edge, and most newer browsers. Global support sits around 92%. The remaining gap is mostly older Safari, older Firefox (pre-93), and legacy enterprise browsers. AVIF support in image editors and design tools is patchier than WebP.
For web delivery, both WebP and AVIF are safe if you provide a JPG fallback using the <picture> element:
<picture>
<source type="image/avif" srcset="photo.avif">
<source type="image/webp" srcset="photo.webp">
<img src="photo.jpg" alt="...">
</picture>
The browser picks the best format it supports.
Encoding speed in practice
If you’re compressing a single image for a blog post, the encoding speed difference doesn’t matter — we’re talking seconds. If you’re processing a catalogue of 50,000 product photos, it matters a lot.
Rough encoding times for a 4000×3000 photograph on a modern laptop:
- JPG (quality 75): 0.1 seconds
- WebP (quality 75): 0.3 seconds
- AVIF (quality 75): 3-8 seconds (depending on encoder and effort setting)
AVIF encoders have an “effort” or “speed” setting. Higher effort = smaller files but much slower. For batch processing, using a lower effort setting often makes AVIF practical at the cost of 5-15% larger output.
When to use each
Use JPG when
You need guaranteed compatibility with any tool anywhere — email, Office docs, legacy systems. You’re exporting images for print workflows or stock photography. You’re encoding on the fly and need maximum speed (thumbnail generation at scale). Basically: whenever you need the file to work everywhere without thinking about it.
Use WebP when
You’re delivering web images and can provide a JPG fallback, or your audience is all modern browsers. You need transparency and a photograph-style image (JPG can’t do transparency; WebP can). You want a drop-in replacement for both JPG and PNG. You’re balancing compression and encoding speed — WebP is the pragmatic choice.
Use AVIF when
You want the smallest possible files and encoding speed doesn’t matter — pre-processed hero images, cached CDN content. You’re targeting modern browsers specifically. You’re working with HDR or wide-gamut content and need the colour fidelity. Or you need animation at high quality (AVIF does short animations beautifully, beating GIF and APNG by huge margins).
What happens if you serve WebP/AVIF without a fallback?
Older browsers or non-browser clients — some email clients, Office, certain screen readers — will display a broken image icon or nothing at all. The user sees missing content. Always use <picture> with a JPG or PNG fallback unless you control the client and know it supports the format.
The recommended setup for a typical website
For 2026, a sensible default is:
- Keep a master of each image in its original format (camera JPG, Photoshop PSD, etc.)
- Export JPG at quality 85 as the universal fallback
- Export WebP at quality 75 as the primary web format
- Optionally export AVIF at quality 70 for maximum savings
- Use
<picture>to let the browser pick
If you want to keep things simple and skip AVIF, WebP alone gets you 25-35% savings vs JPG with minimal operational overhead. That’s already a huge win.
Whatever formats you end up using, the main thing is: just stop serving uncompressed images. JPG quality 95 for web is the equivalent of printing your website on glossy photo paper when a PDF would do. The Image Compressor accepts JPG, PNG, and WebP and has a live quality slider — it’s a fast browser-side tool for reducing file size within your current format.