What is AVIF?

AVIF is a still frame from the AV1 video codec, wrapped in an image container. Video codecs have received enormous engineering investment — every percentage point saved matters across billions of hours of streaming — and AVIF inherits all of it.

Where JPEG offers one block size and one prediction strategy, AV1 offers many: variable block sizes down to 4 × 4 and up to 128 × 128, dozens of prediction modes, and sophisticated filtering to suppress artefacts. The encoder tries far more possibilities and picks the cheapest.

That is also precisely why it is slow. The gain comes from searching a much larger space.

Higher bit depth. 10- and 12-bit colour, which largely eliminates the banding that 8-bit formats show across wide gradients.

HDR and wide gamut. Genuine high dynamic range with the metadata to describe it, which matters as more displays support it.

Better low-quality behaviour. AVIF at very low bitrates stays coherent where WebP goes soft and JPEG breaks into squares — useful for thumbnails and placeholders.

Encoding time. Often ten times a JPEG encode or worse, depending on the effort setting. For a build pipeline processing images once, that is fine. For anything encoding on demand, it is a real constraint.

Decode cost. Higher than JPEG, which is measurable on low-powered devices displaying many images.

Tooling. Support outside browsers is thinner than WebP's, and thinner still in ordinary desktop applications.

Small images. AVIF carries more container overhead, so for very small images — icons, tiny thumbnails — it can be larger than WebP.

Every tool here encodes through the browser's own canvas. Chrome and Firefox can display AVIF but cannot write it — there is no AVIF encoder exposed to canvas.toBlob.

Worse, when a canvas is asked for a format it cannot write, it does not fail: it silently returns a PNG. An "AVIF compressor" built this way would hand most visitors a PNG with the wrong extension. So the tools here probe what your browser can genuinely encode and disable anything it cannot, and there is no AVIF page pretending otherwise.

Producing AVIF in a browser requires shipping a WebAssembly encoder of a megabyte or more. That is a defensible thing to build; it is not something to imply you already have.

If you have a build pipeline that can generate multiple formats, serve AVIF first, WebP as the fallback, JPEG last. That captures the most bytes for readers whose browsers support it.

If you are optimising images by hand, WebP alone captures most of the available benefit at a fraction of the effort, and every current browser supports it.