AVIF vs JPEG
Both store photographs, but they make different trade-offs. Here is where they actually differ, and how to pick.
Short answer
AVIF is roughly half the size of JPEG at the same visual quality. That is the largest single saving available to a website today, and the price is encode time plus a fallback for older Safari.
Why this comes up
JPEG's compression design was finalised in 1992. AVIF is derived from AV1, a video codec from 2018 built by companies with enormous bandwidth bills. Thirty years of research separates them, and unusually for this kind of comparison, the newer format's advantage is not marginal — it is close to a factor of two. The interesting question is therefore not whether AVIF is better but what it costs to adopt.
Side by side
| Property | AVIF | JPEG |
|---|---|---|
| Compression | Lossy | Lossy |
| Transparency | Yes | No |
| Typical file size | 40-55% of an equivalent JPEG | 100% of an equivalent JPEG |
| Compatibility | All current browsers; some older desktop apps lag behind | Opens everywhere, including decades-old software |
| Usually comes from | Websites optimising page weight | Digital cameras and photo sharing |
What actually differs
The size gap is real and it is the point
At matched visual quality AVIF typically lands at 40–55% of the JPEG file. On a gallery page carrying two megabytes of photographs, that is a megabyte back. Unlike most format upgrades, you do not need to squint at the numbers to see whether it was worth it — it shows up directly in load time on slow connections.
AVIF handles gradients where JPEG visibly fails
JPEG's 8×8 block transform produces banding on smooth gradients — a clear sky, a studio backdrop, a dark scene — and the usual fix is to raise quality, which throws away the size advantage. AVIF's transform handles large smooth regions without banding at far lower bitrates. If your images are product shots on seamless backgrounds or anything with a lot of sky, this difference is more visible than the file size.
Encoding is slow enough to change your workflow
AVIF encoding costs an order of magnitude more CPU than JPEG. In a browser tool that means visible waiting on a large image. In a build pipeline it means your image step goes from seconds to minutes, and you will want caching so it only runs on changed files. Decoding is fast, so this is a producer cost, not a visitor cost.
Which to use
Use AVIF for
Web delivery with a fallback in place, especially photo-heavy pages where halving image weight is the single biggest performance win available.
Use JPEG for
Files handed to other people, anything that must open without question, and pipelines where encode time cannot absorb a tenfold increase.
One thing that catches people out
Do not convert an existing JPEG and expect the full saving
Re-encoding a JPEG into AVIF starts from data that has already been through lossy compression, artefacts included. You get a smaller file, but AVIF is now spending bits preserving JPEG's blocking rather than the original detail. The clean saving comes from encoding AVIF from your lossless master. If all you have is the JPEG, convert anyway — just know the result is not the benchmark figure.