A bitmap has no compression to undo, so the conversion is pure arithmetic
Most format conversions swap one compression scheme for another. This one does not. A standard BMP writes each pixel out in full, row after row, with no attempt at shrinking anything. A 1920 by 1080 photo saved as a 24 bit bitmap occupies about 5.9 MB whether the picture is a sunset or a blank white rectangle. The same photo as a JPEG at quality 88 lands somewhere near 250 KB. Nothing clever happened. The bitmap was simply storing raw numbers, and JPEG stopped doing that.
Because the input is raw, the interesting part of a BMP is its header rather than its pixels. The panel above reads those bytes directly and reports the color depth, the compression flag, the row order and the padding the format inserts at the end of every row. Those five fields predict the file size to within a few bytes, and when a bitmap refuses to open they tell you which one is at fault.
Where the megabytes actually go
BMP pads each row of pixels out to a multiple of four bytes. The row length is fixed by this formula, and the file size follows from it:
rowStride = floor((bitsPerPixel * width + 31) / 32) * 4
pixelBytes = rowStride * heightTake a 1000 by 800 image at 24 bits per pixel. Each row holds 3000 bytes of color, which is already a multiple of four, so the stride stays at 3000 and the pixel data reaches 2.4 million bytes. Change the width to 999 and each row now holds 2997 bytes of color, padded up to 3000. You paid for 2400 wasted bytes to gain nothing. At 1 bit per pixel the padding gets absurd, since a 33 pixel wide monochrome image still burns 8 bytes per row.
This is also why the readout shows a row order. Bitmaps store their rows from the bottom up by default, a decision inherited from the coordinate system of early Windows graphics. A negative height in the header flips it to top down. Neither affects what you see here, since the browser sorts it out during decode, but a file written by hand with the wrong sign arrives upside down, and the header is where you confirm which convention it used.
Reading the header panel
The DIB header size is the first useful number, because it identifies the era and the writer of the file. The compression field matters more, since two of its values stop a browser cold.
| Field value | Meaning | Converts here |
|---|---|---|
| Header 12 bytes | BITMAPCOREHEADER, the OS/2 1.x original | Usually yes |
| Header 40 bytes | BITMAPINFOHEADER, what almost everything writes | Yes |
| Header 108 or 124 | BITMAPV4 or V5, adds color space and alpha masks | Yes |
| Header 64 bytes | OS/2 2.x extended header | Often not |
| BI_RGB | No compression, the plain case | Yes |
| BI_BITFIELDS | Custom channel masks, common at 16 and 32 bit | Usually yes |
| BI_RLE8 or BI_RLE4 | Run length packing for indexed images | No, browsers skip it |
| BI_JPEG or BI_PNG | A whole JPEG or PNG wrapped in a BMP shell | No, and it needs no conversion |
Color depth changes what the conversion is worth. An 8 bit bitmap carries a palette of 256 entries and one index byte per pixel, so it was already fairly compact. Sending it to JPEG often saves less than you expect, and the encoder adds faint noise inside the flat palette regions on the way. A 24 or 32 bit bitmap is where the large drops live.
Quality settings for the three kinds of BMP people convert
Numbers on a slider mean little on their own. What matters is where the bitmap came from, because BMP survives in a handful of specific places and each one wants a different setting.
- Scanner and fax output, 94. Flatbed drivers and document capture software still write BMP by default. Scans hold fine grain, dust and paper texture, and dropping below the low nineties turns that texture into visible blocking around text. If the scan is a signed document going into an archive, stay at 94 or keep the file as PNG.
- Photographs and rendered artwork, 88. Continuous tone with gradual color change is the case JPEG was built for. At 88 the difference from the source is hard to find at ordinary zoom, and the file usually lands between four and six percent of the bitmap it came from.
- Screen captures and Paint drawings, 76 or leave them alone. Windows Paint saved BMP for decades, and captures pasted into Paint are still a common source. These images are flat color with hard boundaries, which is the worst case for JPEG. If the capture holds no small text, 76 is fine. If it holds a menu, a code listing or a spreadsheet, convert to PNG instead.
The quality percentage is not a portable measurement. Each encoder maps the number onto its own quantization tables, so 88 on this page and 88 in a desktop editor are different files. Read the byte count in the ledger rather than trusting the number to travel.
When PNG is the better target
Both formats will shrink a bitmap dramatically, so the choice is about what kind of damage you accept.
- Anything with text in it. JPEG rings around hard edges. Letter shapes are nothing but hard edges. A screenshot of a terminal window converts to a fuzzy mess at any quality worth the size saving.
- Indexed bitmaps at 8 bit or below. The palette already limits the image to 256 colors or fewer, which is exactly what PNG compresses well. Run one through BMP to PNG and compare the two outputs before committing.
- Icons, logos and diagrams. Flat regions with sharp boundaries. PNG stores them losslessly and often smaller than the JPEG.
- Files you will edit again. JPEG loss compounds on every save. Keep a lossless master and export to JPG once, at the end.
- 32 bit bitmaps you need to stay transparent. JPEG has no alpha channel. The fill color in the panel above is permanent once you download.
Bitmaps your browser will refuse to decode
The decoder here is the browser image pipeline, which covers the common cases well and ignores several corners of the specification. When a file fails, the header readout still appears, because the parser runs on the raw bytes before any decoding is attempted. That is the point of showing it. Instead of a blank error you get the field responsible.
- Run length encoded bitmaps. BI_RLE8 and BI_RLE4 pack repeated palette indices. Chrome and Firefox both decline them. Open the file in an image editor and re-save it as uncompressed BMP or PNG first.
- Embedded JPEG or PNG. BI_JPEG and BI_PNG wrap a complete file of that type inside a BMP container. They exist mainly for print spoolers. Rename the payload and you already hold the format you wanted.
- OS/2 2.x files with a 64 byte header. Rare outside legacy systems, and support is patchy.
- CMYK bitmaps. The BI_CMYK variants come out of prepress software and have no path through a browser canvas.
- Files renamed from another format. A JPEG called photo.bmp fails the signature check on the first two bytes, and the readout says so rather than guessing.
Where this converter stops
- One file at a time. The header panel is per file and the layout depends on it, so there is no batch queue here. For a folder of images, the image format converter handles bulk work.
- Baseline output only. The canvas encoder gives no way to request a progressive JPEG, and no way to set chroma subsampling. An earlier version of this page showed a progressive toggle that could not do anything, so it has been removed.
- No metadata to carry across. This one costs you nothing. BMP holds no EXIF block and no ICC profile beyond the color space fields in V4 and V5 headers, so there is almost nothing to lose. Pixel density in dots per inch is reported in the readout and does not survive the conversion.
- Output dimensions match the input. Resize first with the image resizer if you want fewer pixels as well as fewer bytes.
- Memory sets the real ceiling. A decoded image occupies width times height times four bytes. A 12000 by 9000 pixel scan needs over 400 MB of canvas before encoding starts, which phones will not give you.
