Convert JPG to AVIF

No — that is the whole reason I built this. The conversion runs in your browser using WebAssembly, so your files never leave your device; there is no server in the loop at all. It also means the tool keeps working offline once the page has loaded, and there is no file size limit beyond your device’s memory.

Typically 40–60% smaller at equivalent visual quality. The win is biggest on smooth gradients, skies and dark areas, where JPEG wastes bytes fighting its own blocking artifacts. The per-file readout shows your exact numbers before you download.

Any lossy-to-lossy conversion involves some loss, and I would rather say so plainly. In practice, at quality 60+ the AVIF preserves everything you can see in the JPEG. What you should avoid is repeatedly round-tripping between lossy formats — convert once, from the original.

Yes — all current browsers render AVIF. The standard pattern is a <picture> element offering AVIF first, WebP second and JPEG last; browsers pick the best they support. If your audience skews to current Chrome/Firefox/Safari, plain <img src="photo.avif"> is already safe.

AVIF spends far more effort searching for compression opportunities — that is where the extra 20–40% savings over WebP come from. Everything still runs on your device; a typical 12-megapixel photo takes a few seconds.

AVIF wins on pure bytes — around half of JPEG, versus WebP’s roughly a third off — and it degrades more gracefully on gradients and night shots. WebP wins on encode speed and slightly older device support. My split: AVIF for the pages where images dominate load time, JPG to WebP for bulk galleries where encoding thousands of files matters.

Your originals, always — treat the camera JPG as the negative and never overwrite it. Also skip AVIF for photos leaving the browser ecosystem: printing services, marketplaces and most email clients still want JPG. And heavily re-compressed memes gain almost nothing; the artifacts are already baked in.