A 2 MB JPG photo lands as a 35 MB BMP. Nothing broke. BMP stores every pixel as raw bytes with no compression pass at all, so the output size follows straight from width, height, and bit depth. The queue above prints that number before you convert, which beats finding out after a folder of holiday photos fills a USB stick.
The size of a BMP is arithmetic, not a guess
JPEG size depends on image content. Bitmap size does not. Each row of pixels gets padded out to a multiple of four bytes, then every row is written end to end after a 54 byte header.
file size = header + (row bytes x height)
A 4000 x 3000 photo at 24-bit works out to 12000 bytes per row and 36,000,054 bytes on disk. Shoot the same scene at a higher JPEG quality and the BMP stays exactly that size, because the format has no quality dial to turn.
Three bit depths, three different files
The dropdown above changes both the byte layout and the size total. Pick by what reads the file, not by which number looks bigger.
| Depth | Bytes per pixel | Written for |
|---|---|---|
| 24-bit BGR | 3, rows padded to 4 | The default almost every reader accepts |
| 32-bit BGRA | 4, no padding needed | DirectX textures and tools wanting word-aligned rows |
| 8-bit grayscale | 1, plus a 1024 byte palette | Scans, OCR input, embedded displays |
The alpha byte in the 32-bit output is set to fully opaque on every pixel, since JPEG carries no transparency to begin with. You are paying a third more disk space for row alignment, not for a real alpha channel. The grayscale mode averages channels with the luma weights (77, 150, 29) and writes a matching 256 entry palette, so a color photo drops to roughly a third of its 24-bit size and loses hue permanently.
Bottom-up versus top-down rows
Original Windows bitmaps store the bottom row of the image first and record a positive height in the header. The top-down variant writes rows in reading order and records a negative height instead. Both are legal. Both produce byte-identical file sizes.
- Bottom-up is the safe pick. Legacy Win32 apps, older Delphi and VB tooling, and a fair share of embedded parsers assume it.
- Top-down suits code reading rows into a buffer sequentially, since no row reversal is needed on load.
- Some strict parsers reject negative heights outright. When a file opens as a blank or vertically mirrored image somewhere else, switch this setting and write it again.
Converting to BMP recovers nothing. JPEG discarded detail when the photo was first saved, and blocking artifacts around sharp edges survive the trip into the bitmap at full fidelity. What you get is a lossless copy of an already lossy image, sitting in a much larger file. If the goal is archiving without further loss, JPG to PNG reaches the same fidelity at a fraction of the size.
Where a raw bitmap still earns its place
- Embedded firmware and microcontroller displays where a JPEG decoder does not fit in flash and a linear pixel array does.
- Industrial and medical imaging software with import filters written decades ago and never touched since.
- Game engine texture pipelines that import BMP as an intermediate and compress on their own terms.
- Pixel-level test fixtures where a known byte layout matters more than file size.
- Print and RIP workflows handed a raw raster instead of a compressed source.
Running a batch
- Drop the JPGs in. Each row shows its pixel dimensions next to the size the bitmap will take.
- Set bit depth. Watch the growth figure move before committing to anything.
- Leave row order on bottom-up unless the target software asked for otherwise.
- Write the files, then download each card. Names carry over with the extension swapped.
Every file is read, drawn to a canvas, and encoded by JavaScript inside this page. No request carries your photo anywhere, which also means the browser tab holds the whole uncompressed buffer in memory. Twenty phone photos at 24-bit runs near a gigabyte of allocation. Split large folders into smaller runs when the tab starts crawling.
What this page will not do
No resizing, no cropping, no RLE-compressed BMP variant, and no 16-bit or 1-bit output. Failed decodes are reported per file rather than silently skipped. Animated or progressive sources outside the JPEG family are rejected at the drop zone instead of half-converted.
Nearby conversions
Going the other direction is BMP to JPG. Transparent sources belong on PNG to BMP, which keeps alpha in view before flattening. Frame-by-frame work starts at GIF to BMP, and a heavy source folder deserves a pass through the image compressor first.
Encoder rewritten and tested August 2026 against 24-bit, 32-bit, and 8-bit output in Chrome, Firefox, and Safari. Headers follow BITMAPINFOHEADER at 40 bytes.
