AVIF Support: Displaying Is Not Encoding.

A format can work in one direction

Image support is often described as a single checkbox, but reading and writing are different operations. A browser can contain a decoder for a format without exposing a corresponding canvas encoder. A tool built on canvas must test the export path it actually uses rather than relying on a general browser-compatibility statement about displaying images.

This distinction is visible in our measured dataset. The tested Chromium browser could be asked for AVIF output, but its canvas export returned a different type. The benchmark records the attempt as unsupported instead of counting the returned PNG bytes as an AVIF result. The same verification is part of the product’s format controls.

Fallback behavior needs an explicit check

MDN documents that an unsupported requested canvas export type falls back to PNG. That behavior keeps the browser API usable, but it can mislead a converter that assumes the request succeeded. A file with PNG contents and an AVIF extension is not an AVIF conversion, even if an image viewer happens to recognize it by its contents.

The application should compare the returned MIME type with the requested type. If they differ, it should explain the limitation or offer a clearly labeled supported output. A benchmark should retain the unsupported attempt so that readers can understand why a format is missing from the size comparison.

Worked example: a capability test

Create a small canvas and request an AVIF blob. Inspect the blob type before saving anything. If it is image/png, the relevant encoder is unavailable in that environment. Choose PNG, JPEG or WebP only when those paths pass their own capability check. This is a functional test, not an inference from the browser’s name.

For a real source conversion, decoding still comes first. An AVIF-to-JPEG workflow can succeed where JPEG-to-AVIF cannot, because the two operations use different capabilities. The converter page explains the direction rather than presenting all format pairs as symmetric.

Do not invent an AVIF benchmark

A valid format-size comparison needs files actually encoded in the claimed format, with the input and settings recorded. A missing encoder is a result about the tested environment. It is not evidence that the format is universally unsupported, and it is not a reason to fabricate a size by copying another format’s output.

Our table keeps unsupported values empty and identifies the browser used. Repeating the test elsewhere may produce different capability results. Record that environment and verify the actual output before comparing byte counts or making a delivery recommendation.

Choose for the destination

Even when AVIF encoding is available, the receiving application must accept the file. A web page, marketplace uploader and desktop editor can have different requirements. Use the format that completes the actual workflow, and preserve an appropriate master so that another delivery format can be produced later.

A newer format is not automatically the best choice for a small one-off task. Compatibility, transparency and visual quality all matter. The local converter keeps the decision explicit and reports what the browser can actually produce today.