Convert JPG to AVIF

Why this one takes a few seconds

AVIF is a still frame of AV1 video compression, and video compression is expensive to produce and cheap to consume. That asymmetry is the whole explanation for the wait: the encoder is searching through a very large space of ways to describe your picture, and the searching is what buys the size. A few seconds for a large photograph is normal and is not a sign that anything is wrong. Decoding, by contrast, is instant — which is the right trade for a picture encoded once and viewed many times.

What you get for it is roughly half the size of a JPEG at the same perceived quality, and better behaviour where JPEG is weakest. Smooth gradients — skies, studio backdrops, shadows — come out without the banding JPEG puts into them, and the 8×8 blocking that appears in a heavily compressed JPEG simply does not happen. AVIF also carries transparency and wide-gamut colour, neither of which JPEG can hold at all.

Start from the best original you have. Re-encoding a JPEG means the AVIF encoder inherits the JPEG's artefacts and cannot distinguish them from real detail, so it spends real bits preserving someone else's damage — the result is both larger and worse than encoding the same picture once from a PNG, a RAW export or a camera original. If you have the original, use it; if the JPG is all there is, keep the quality high enough that the second generation adds nothing visible.

Support is now good and not universal, and the distinction matters for what you do with the file. Every current browser decodes AVIF, so for a website it is simply the better format. Outside the browser it is patchier — some image viewers, older phones, email clients and design software still do not read it — so an AVIF emailed to someone is a gamble in a way a JPG never is. Camera and location metadata are not carried across.

When you want something else

The reference encoder gives you the dial this page cannot. avifenc -s 4 --min 20 --max 30 in.jpg out.avif trades encoding time against size explicitly — -s 0 is the slowest and smallest, -s 10 is nearly instant and noticeably bigger — and --jobs all uses every core, which matters enormously on a folder of hundreds. Nothing in a browser can spend two minutes on one photograph, and sometimes two minutes is exactly what the file is worth.

For a website, the format is only half the job. Serving AVIF with a JPEG fallback through a picture element, or letting a CDN negotiate the format per visitor, gets the size win without the compatibility risk — and sharp or libvips in a build step will generate every variant automatically, which is how this is done at any scale beyond a handful of images.