Convert BMP to AVIF

An AVIF file is, structurally, a still frame of AV1 video in a container the Alliance for Open Media specified in 2019. It inherits the compression work of a modern video codec, which is why it beats WebP and JPEG on photographic material at the same visible quality.

It inherits the cost as well. The registry lists slow encoding as the format’s known problem, and the pipeline here agrees with it: decoding is the long pole for a large photograph in every other conversion, and for this one the encode is. A twelve-megapixel bitmap — a 4000 by 3000 image, 36 MB as a BMP — takes long enough that the progress bar is doing real work rather than reassuring you. That asymmetry is worth internalising, because it inverts the usual intuition. The bitmap is the huge file and the cheap one to read; the AVIF is the tiny file and the expensive one to write.

AVIF holds twelve bits per channel and describes wide colour spaces. Those two capabilities are most of the reason the format exists, and they are the reason it is the delivery format for HDR photography.

A BMP holds eight bits per channel in plain RGB. There is no wider gamut in the source, no extra dynamic range, no colour profile — the registry records no metadata containers for BMP at all. So the headroom in the AVIF stays empty, and the only benefit you are collecting from this conversion is the compression. That is a real benefit; it is just worth knowing it is the only one, because a great deal of what is written about AVIF is about the capabilities a bitmap cannot reach. A format never adds information: it can only describe what arrived, and what arrived here is eight-bit sRGB from a format Microsoft published in 1987.

It runs as WebAssembly inside the browser tab, on whatever processor the machine has. There is no server doing the work, which is the reason nothing is uploaded and also the reason a batch of large bitmaps is something you start and come back to.

The practical shape of it: one moderate image is a wait, and a folder of forty scanner outputs is a coffee. If that is unacceptable and the audience is broad anyway, WebP is one page away and encodes in a fraction of the time for a file that is usually within a modest margin of the AVIF. Nothing about this is a defect in the conversion — the same encode on a server would take comparable work, it would simply be somebody else’s processor and your file would have to travel to reach it. The time is the honest price of the picture never leaving the machine.

The registry classes AVIF as supported by modern browsers, and that word is doing real work next to the "all" it gives WebP and JPEG. Current desktop and mobile browsers read AVIF; older devices, some in-app browsers and a good deal of email software do not.

Which makes this a format to serve rather than to send. As an attachment or a file handed to somebody else it is a poor choice, and the fact that it opens on your machine says little about theirs. The same caution applies to design and editing tools: support there has arrived unevenly, and an AVIF that a browser displays perfectly may still be a file a colleague cannot place in a document.

The mechanism that makes the support gap survivable is the picture element: several sources listed in order, each with its type, and the browser takes the first one it understands. Put the AVIF first, a WebP after it and a JPEG last, and every visitor gets the smallest file their browser can actually decode without any detection code running.

That means converting the same bitmap twice, and it is the reason the batch on this page is often run alongside the WebP one. It is worth doing in that order rather than converting the AVIF from the WebP: each lossy encoder makes its own decisions about what to discard, and stacking two of them produces a file that carries both sets of losses for no saving. Always encode each delivery format from the bitmap itself.

AVIF carries an alpha channel, and nothing on this path flattens the image or asks for a background colour, so a 32-bit bitmap keeps its see-through areas. The 24-bit files that make up most of what arrives here have none to keep.

The quality control defaults to 82, the same number every lossy target on this site offers, and it is worth remembering that the scale belongs to the encoder rather than to the picture. Eighty-two in AVIF and eighty-two in JPEG are not the same amount of loss or the same file size, so comparing two formats means comparing the outputs, not the settings. AVIF also tends to fail differently: where JPEG breaks into blocks and ringing around edges, AVIF smooths fine texture away, which is less obviously wrong and easier to miss until the image is next to the original.

When the audience includes old devices. When the image is small enough that the difference is a few kilobytes. When the material is flat artwork with hard edges, where AVIF’s advantage narrows and can invert. And when you are converting hundreds of files and the encoding time is the constraint that actually matters.

AVIF earns its cost on large photographic images served to a modern audience through a picture element. That is a specific case rather than a default, and a page that told you otherwise would be selling the newer format rather than describing it. The test that settles it costs a minute: convert one representative bitmap to both, put the two byte counts next to each other, and decide whether the difference justifies a second encode of every file and a fallback in the markup. Sometimes it plainly does; often it plainly does not.

It is the one adjustment that improves the file size and the encoding time together, and it is proportional to the pixel count rather than to the width — halving the width of a bitmap removes three quarters of the pixels the encoder has to think about.

Set the maximum width to the widest the image will ever be displayed, doubled for high-density screens. A 4000 by 3000 scan reduced to 2000 by 1500 is still larger than nearly every place it will appear, and the AVIF encode of it finishes in roughly a quarter of the time.

Drop the whole folder and each file converts in turn on your own machine, keeping its name with the extension swapped, with the set returned as one ZIP. The ceiling is 100 MB per file, which is about 33 megapixels of uncompressed bitmap.

Plan the batch around the encode rather than around the download. Files are processed one after another, so the time is roughly the sum of the individual encodes, and the largest images dominate it — a single 33-megapixel bitmap can take longer than thirty small ones. Sorting the obviously oversized files out and resizing them first is worth more than any other change you can make to a batch here, and it is the only one that improves the outputs as well as the wait.

AVIF is a delivery format and this conversion is lossy. What comes out is sized and encoded for the place it is going, and there is no path back from it to the pixels the bitmap held.

If the BMP is your only copy, keep it or convert it to PNG first — that direction is exact and costs a fraction of the disk space. Then produce the AVIF from the master whenever the destination changes, rather than converting a delivery file into another delivery file and stacking one encoder’s losses on another’s.