Convert AVIF to BMP

AVIF was designed in 2019 to make photographs small enough to send over a mobile connection. BMP was designed by Microsoft in 1987 to be a block of pixels a program could read straight into memory, with no compression at either end. Putting the two together produces the biggest multiplier of any pair here.

Neither format is being misused. BMP is not a bad format; it is a format with one job, which is to be trivially readable by software that does not want to implement a decoder — the header says how wide the picture is and the rest of the file is the picture, in order. The size is the price of that, and it was a sensible price when a screen was 640 pixels wide and a bitmap fitted on a floppy disk. It is only the arrival of thirty-megapixel cameras at the other end of the chain that turned a reasonable design into an alarming file.

The arithmetic is fixed and there is nothing in it about the picture. Width times height times three bytes, plus a header. A 1000 by 1000 icon is 3 MB. A 3000 by 2000 photograph is 18 MB. A 6000 by 4000 one is 72 MB.

Now compare that with what you dropped in. A web-delivered AVIF of that 3000 by 2000 photograph is commonly under half a megabyte, which puts the multiplier past fifty before anything unusual has happened. On flat artwork — a logo, a chart, an interface graphic — AVIF does even better, because large areas of identical colour are what any modern codec compresses most aggressively, and the ratio climbs into the hundreds. Nothing about the picture changed; only the honesty of the storage did. It is worth checking the number against your own file before converting a folder, since the multiplier is what decides whether the batch fits anywhere.

Because the size depends on the dimensions alone, there is no quality setting on this conversion and there could not be one. A BMP has no knob to turn: every pixel costs the same four bytes whether it is part of a gradient or part of a white margin.

The maximum width setting is therefore the only lever, and it works by producing fewer pixels rather than cheaper ones. Halving the width quarters the file, because both dimensions shrink together — 3000 by 2000 at 18 MB becomes 1500 by 1000 at 4.5 MB. That is worth knowing when the destination is an embedded display that only ever wanted 480 pixels, where the full-resolution bitmap is not merely wasteful but too large for the device to hold. Sending an unresized bitmap to a small screen is the most common way this conversion produces a file nobody can use.

BMP is less one format than a small family. It can store pixels as full colour or as an indexed palette of up to 256 entries, at several bit depths, and a specification that says "BMP" without saying which of those it means has not finished the sentence. What comes out of this conversion is a full-colour bitmap at four bytes per pixel.

That is what almost everything reads, and it is not universally what is asked for. Firmware for a small display is the usual exception: an embedded panel with limited memory often names 24-bit or an 8-bit indexed palette specifically, because that is what its framebuffer holds. Read the documentation before converting, and where it names a variant this does not produce, IrfanView and GIMP will both re-save a BMP into the depth the device wants in a single step.

AVIF can store twelve bits per channel and a wide colour gamut, which is why it carries HDR photography on the web. The BMP written here is eight bits per channel in ordinary RGB, the shape every reader of the format expects.

For a normal web image nothing is lost, because eight bits is all it ever held. For an HDR source the extra range is discarded, and the visible symptom is a flattened sky or a highlight that clips rather than rolls off. If that matters, the reduction should be done deliberately in an editor that lets you choose how the range is mapped, not as a side effect of reaching a format from 1990.

AVIF carries a full alpha channel and a BMP, as every program that consumes one expects it, does not. So the see-through pixels are filled with a colour chosen before the conversion, and the fill is permanent — the transparency is replaced rather than hidden.

Choose the colour the image will sit on rather than a neutral one. Anti-aliased edges are partly transparent, so they are blended with your choice: against the intended background the edge stays smooth, and against a different one the artwork carries a faint halo all the way round. That halo is the classic sign that a mark was flattened onto white and then placed on something dark, and it cannot be removed afterwards without redoing the conversion from the AVIF. For an instrument or a panel the exact colour is usually written in the documentation you were given, which makes this a lookup rather than a judgement.

This is the useful asymmetry and it is why the conversion happens in a browser. The software waiting for the BMP — the instrument, the panel, the till, the twenty-year-old Windows utility — has no AVIF decoder and never will. The operating system it runs on may not have one either.

A browser does. The AVIF is decoded by the same code that draws it on a web page, so this works on a machine where double-clicking the file does nothing at all, and produces a file that machine can then handle without any further software being installed. That is a better answer than installing a codec pack on a controlled system, and on a machine you are not allowed to install anything on it is the only answer.

Convert at the boundary and keep the AVIF. It is a fraction of the size, it still has its transparency, it still has its full colour range, and it is what you will want if the destination ever changes or the device is replaced.

Sending a BMP to a person rather than a machine is almost always a mistake for the same reason. It fills an inbox, it clogs a shared drive, and there is nothing in it that PNG would not carry losslessly at a fraction of the size while keeping the transparency you had to destroy here. BMP is a wire format for equipment that asked for it, and treating it as a storage format is how a project ends up with a hundred gigabytes of images it could hold in two.

AVIF can hold a sequence of frames, and this is one of the things it inherited from the video codec underneath it. A BMP holds one still image and has no concept of a second one.

So if what you have is a short animation, this conversion is not a lossy version of what you wanted — it is the wrong destination entirely. MP4 keeps the movement at a sensible size and GIF keeps it in something ancient software understands, and either is a better answer than a single frame in a very large file. If the device genuinely wants a sequence of bitmaps, which some small displays do, the frames have to be extracted first and each one converted, and that is a job for a script rather than for a drop zone.

Drop up to 100 files at once: each converts in turn, keeps its name with the extension swapped, and the batch returns as one ZIP. A hundred is where the free batch stops, and anything past it is dropped rather than queued. Nothing is uploaded, so there is no queue, no account and no daily allowance.

The planning constraint is the output rather than the input. Forty photographs at 3000 by 2000 are over seven hundred megabytes of bitmap being held in a browser tab while the archive is built, and a batch that would be trivial in any other format is not trivial here. Convert in small groups, save as you go, and set a maximum width if the destination does not need the full resolution.