AVIF: the small one this bench will not run yet

AVIF is a still picture stored as a single frame of AV1 video. It inherits that codec’s machinery — many block sizes, many prediction modes, a search that considers a great number of ways to describe each region — and that machinery is why it routinely produces the smallest file of anything a browser can display.

It is also why encoding one is slow. The decoder is cheap and the encoder is expensive, which is an excellent trade for a website serving a million readers and a poor one for a page that has to encode your picture while you wait for it.

There is no AVIF card on the bench for that reason, and this page exists instead of a card that would lie about the wait. The numbers behind the decision are below rather than in a footnote: they were measured on this project, from a file that was downloaded and run, and nothing here is quoted from a table.

The rows below are about software a file will actually be handed to, not about a specification. A format is supported when the person you sent it to can open it.

This is the whole problem. On this project's own measurement, a single-threaded WebAssembly build of the reference encoder took 3.3 seconds to write one 12-megapixel picture on an Apple-silicon laptop at its fastest useful setting, and 12.9 seconds at a moderate one — before any quality search, which multiplies that by up to seven. The encoder binary is 3.3 MB. On a mid-range phone the honest number is minutes, and there is no way to present minutes as a wait. See BUILD-NOTES in the repository for the measurements.

• Encoding is slow enough to be a product decision rather than a detail, which is why this site does not offer it yet.
• Decoding is cheap, so a page that serves AVIF is fast even where writing one was not.
• Some encoders default to a chroma configuration that softens saturated reds more than the file size would suggest.
• Re-encoding an AVIF as another AVIF is a second lossy pass, not a copy.

Pictures served from a web page, encoded once on a machine that has time, to an audience using current browsers. That is the case AVIF was designed for and it wins it clearly.

It is the wrong answer for a file you are sending to a person rather than serving to a browser. Windows will not preview one without an extra codec installed, and most desktop software of any age simply will not open it — and a file the recipient cannot open is not a smaller file, it is a failed delivery.

When will this bench encode AVIF?

When an encoder lands that can do a 12-megapixel picture in a time this page can honestly present. Cross-origin isolation is the obvious route to a multi-threaded build, and it is not available here because the headers it needs break the advertising this site carries. That trade is recorded rather than worked around.

How slow is it really?

On this project's own measurement: 3.3 seconds for a single 12-megapixel pass at the encoder's quickest useful speed setting, and 12.9 seconds at a moderate one, on an Apple-silicon laptop running the WebAssembly build single-threaded. The quality search this bench runs needs up to seven passes. A mid-range phone is several times slower again.

Can this site open an AVIF file?

Yes. Decoding is cheap and the browser does it natively, so an AVIF you already have can be opened here and compared against the other formats. It is the writing that is expensive, not the reading.

Is AVIF always smaller than WebP?

Usually on photographs, sometimes by a lot, and not always. On drawn pictures with hard edges the gap narrows or reverses, and the support difference between them is real, so a small win is not automatically worth taking.

Does re-encoding an AVIF as AVIF lose anything?

Yes. It is a second lossy pass, not a copy, and it accumulates the same way a second JPEG save does.

Encoding happens on this machine; the file stays where it is.