A 24-bit BMP photograph is 10–50× larger than the same image saved as AVIF, because BMP stores raw pixels with no real compression. Microsoft and IBM created the format for Windows and OS/2 in the 1980s, when "decode" meant copying bytes into video memory. On the modern web it is a liability: convert any BMP to AVIF for delivery, or to PNG when you need lossless pixels. This page quantifies the gap and gives the conversion workflow.
Where BMP came from
BMP is Microsoft's Device Independent Bitmap, shipped with Windows and OS/2 in the late 1980s. The name is interchangeable with DIB, its in-memory twin used for the Windows clipboard. Three design facts still shape it today:
- It predates practical web compression — no DCT, no entropy coding by default.
- It stores colour values device-independently so any Windows app reads it without a codec.
- It survives mainly in clipboard, screen-capture, and embedded contexts, not on websites.
The goal in 1987 was zero decode cost, not small files. AVIF inverts that priority entirely: maximum compression, heavier decode. See the BMP file format reference for the full header history.
Why BMP files are enormous
A BMP records every pixel as literal bytes, so size scales directly with resolution and bit depth. The uncompressed payload follows a fixed formula:
rowSize = floor((bitsPerPixel × width + 31) / 32) × 4 // padded to 4 bytes
fileSize = rowSize × height + headers (≈54 bytes)
Each 24-bit pixel costs exactly 3 bytes, with every row padded to a 4-byte boundary. Worked examples at 24-bit colour:
| Image | Pixels | BMP (24-bit) | AVIF (q≈55) | Ratio |
|---|---|---|---|---|
| 1920×1080 | 2.07 M | ~6.2 MB | ~150 KB | ~40× |
| 3000×2000 | 6.0 M | ~18 MB | ~400 KB | ~45× |
| 800×600 | 0.48 M | ~1.4 MB | ~40 KB | ~35× |
The 6.2 MB figure for a single 1080p frame matches the formula above (Wikipedia). AVIF reaches those savings because it codes one AV1 keyframe instead of storing raw bytes. The same source as JPEG would land near 200–400 KB, and AVIF roughly halves that again.
BMP has no compression worth using
BMP technically defines compression modes, but almost every BMP in the wild is mode BI_RGB — fully uncompressed. The alternatives are dead ends for the web:
- BI_RLE8 / BI_RLE4 — run-length encoding for 8/4-bit indexed images, supported inconsistently.
- BI_BITFIELDS — still uncompressed; only redefines channel masks.
- BI_JPEG / BI_PNG — embeds a JPEG or PNG inside the BMP wrapper, which defeats the format.
If a file needs JPEG or PNG compression, ship JPEG or PNG directly. RLE saves bytes only on flat graphics and never approaches a modern codec. For the broader principle, read Lossy vs Lossless Compression.
BMP transparency is unreliable
BMP supports alpha only through its 32-bit variant, and many viewers silently ignore those alpha bits. The problems compound:
- The original specification had no alpha; it arrived as informal convention.
- Apps disagree on straight versus premultiplied alpha, producing dark fringes.
- Some decoders read 32-bit BMP as opaque 24-bit, dropping transparency outright.
For dependable transparency, use a format built for it. AVIF carries full 8/10/12-bit alpha at a fraction of the size, and PNG remains the safe lossless choice. See AVIF vs PNG for the size-versus-compatibility trade-off.
The BMP-to-AVIF workflow
Converting a BMP is almost always pure upside — you discard nothing but wasted bytes. Choose the target by the job:
- Photographs and web delivery — convert to AVIF for the smallest files; see JPG to AVIF and PNG to AVIF for the in-browser converters.
- Lossless archival or transparency — convert to PNG, which keeps pixels exact at a small fraction of BMP size.
- Maximum legacy compatibility — convert to JPG for photos that must open anywhere.
A practical command-line path with ImageMagick:
# BMP → AVIF (lossy, typical web use)
magick input.bmp -quality 55 output.avif
# BMP → PNG (lossless, transparency or fidelity matters)
magick input.bmp output.png
If a legacy tool later needs the pixels back in a common format, use AVIF to JPG or AVIF to PNG — BMP is rarely the right final form. Tune output bytes with the AVIF Optimization guide.
When BMP is still acceptable
Keep BMP only when a downstream system cannot decode anything else. Legitimate cases are narrow:
- Embedded displays and microcontrollers that lack a JPEG or PNG decoder.
- Windows clipboard transfers, where DIB is the automatic in-memory format.
- Intermediate scratch files inside a local pipeline, deleted before delivery.
For every web, email, or cloud-storage scenario, convert first. A 6 MB BMP hero image wrecks performance budgets before a single pixel renders; compare the alternatives in AVIF vs JPG.
FAQ
Is BMP lossless? Yes — uncompressed BMP preserves every pixel exactly, but PNG is lossless too and far smaller, so BMP's fidelity offers no practical advantage.
Why is my BMP so large? Because BMP stores raw RGB bytes with no compression — a 1920×1080 24-bit image is about 6.2 MB regardless of content.
Can I put BMP on a website? Browsers render BMP, but you should never serve it; convert to AVIF or WebP to cut size 30–50×.
Should I convert BMP to AVIF or PNG? Choose AVIF for photographs and web delivery, PNG for lossless archival or reliable transparency — both are dramatically smaller than BMP.
Does BMP support transparency? Only via the 32-bit variant, and inconsistently; use AVIF or PNG when transparency must be reliable.
Sources and further reading
- BMP file format — Wikipedia
- The BMP File Format — University of Alberta
- AVIF format overview — the recommended target for BMP photos
- AVIF vs PNG — choosing a lossless-capable web format
- Lossy vs Lossless Compression — picking a compression mode