Why is the BMP so much bigger than the JPEG?

Because a JPEG is compressed and a 24-bit BMP is not. Every pixel costs three bytes, plus whatever padding its row needs, so a 1600 x 1200 photograph leaves here as 5,760,054 bytes whatever the JPEG weighed. That is the format working as intended: BMP stores the pixels as they are, which is exactly why it is asked for.

Why is the file size not just width times height times three?

Because BMP rows are padded. Each row of the pixel array is rounded up to a multiple of four bytes, so a 2 pixel wide picture writes 6 bytes of colour and 2 bytes of padding, 8 bytes a row, and a 2 x 2 test image is exactly 70 bytes with its header. A width of 1600 needs 4,800 bytes and already lands on four, so it takes no padding at all. Add the 54-byte header and you have the file size.

Can I just rename a .jpg to .bmp instead?

No. The extension is a label and the bytes inside are still JPEG, so anything that reads the file properly will refuse it or show nothing. This tool decodes the JPEG's pixels and writes a new file that starts with the BM signature, states 24 bits a pixel and BI_RGB compression, and points at byte 54 for its pixel data. Hand it a file whose bytes are not JPEG and it names the format it actually found instead of converting.

Does converting to BMP bring back detail the JPEG lost?

No, and nothing can. JPEG throws detail away when it compresses, and a later format cannot invent it back. What you get here is a faithful, uncompressed copy of the picture as your browser decodes it today, with no further loss, rather than a restored original.

Is anything uploaded, and what are the limits?

Nothing is uploaded and there is no account. The tool opens JPEGs up to 25 MB and up to 16 million decoded pixels. Those are memory ceilings for work done inside one browser tab rather than a service limit: a 4000 by 4000 bitmap is 48,000,054 bytes on its own, and the tab has to hold both the picture and the file at once.

Can I resize the picture while I convert it?

Yes, and the aspect ratio is always kept. Set a width and the height follows it, or set a height and the width follows. A 1600 x 1200 picture asked down to 800 wide becomes 800 x 600, with a row stride of 2,400 bytes. Pixel sizes are whole numbers here, so a typed 800.5 is refused by name rather than rounded behind your back.

Will a photo taken sideways come out the right way up?

Your browser decides that, and this tool asks it to honour the EXIF orientation tag when it decodes. The panel on the left shows which tag the file carries, so you can see what was asked for. Colour management is the browser's job too. The tool reports what it found in the file and writes the pixels it was handed.

Which BMP does this write, exactly?

A 14-byte BITMAPFILEHEADER followed by the 40-byte BITMAPINFOHEADER, with one colour plane, 24 bits a pixel, BI_RGB compression, a positive height for a bottom-up pixel array, and the pixel data at offset 54. Every header integer is little-endian, and the field layout follows Microsoft's BITMAPINFOHEADER documentation for the Win32 wingdi API. The tool reads its own output back, and hands the same file to your browser's BMP decoder so the page can say it opens rather than assume it.

JPEG to BMP

Plenty of converters promise a BMP and hand back a renamed JPEG, or a file whose rows are the wrong length and open sheared. This one writes the bitmap here in your browser, byte by byte: a 14-byte BITMAPFILEHEADER, a 40-byte BITMAPINFOHEADER, then 24-bit BI_RGB pixels stored bottom-up in BGR order with every row padded out to a multiple of four bytes. The panel on the right is read back out of the finished bytes rather than predicted from them, and the same file is handed to your browser's own BMP decoder to check that it opens, so the numbers on screen are the file's own. A 1600 x 1200 photograph comes out as 5,760,054 bytes: 54 of header, then 4,800 bytes for each of the 1,200 rows.

Turn a JPEG into a real BMP

or drop one on this stage

Never uploadedNo accountUp to 25 MBUp to 16,000,000 pixels

Size: no file yet
Depth: 24-bit BI_RGB
File: no file yet
Row stride: no file yet

Output size

No JPEG open yet. Choose one, or drop it on the stage, and it is decoded and rewritten in this tab. Up to 25 MB and 16,000,000 decoded pixels.

The whole conversion happens in this tab: your browser decodes the JPEG, a canvas hands the pixels back, and the bitmap is written a byte at a time here. The tool remembers the output size between visits and never a picture.

2 x 2 test image24-bit BMP
70 bytes: 54 header, two 8-byte rows
1600 x 1200, no resizestride 4,800
5,760,054 bytes
Resized to 800 wideaspect ratio kept
800 x 600, stride 2,400

Accuracy. The BMP is written here byte for byte: a 54-byte header, 24-bit BI_RGB pixels stored bottom-up in BGR order, every row padded out to a multiple of four bytes. The pixels are whatever your browser decodes the JPEG to, so colour management and EXIF orientation are the browser's doing, and detail the JPEG already discarded does not come back. Nothing is uploaded.

Common questions

Why is the BMP so much bigger than the JPEG?: Because a JPEG is compressed and a 24-bit BMP is not. Every pixel costs three bytes, plus whatever padding its row needs, so a 1600 x 1200 photograph leaves here as 5,760,054 bytes whatever the JPEG weighed. That is the format working as intended: BMP stores the pixels as they are, which is exactly why it is asked for.
Why is the file size not just width times height times three?: Because BMP rows are padded. Each row of the pixel array is rounded up to a multiple of four bytes, so a 2 pixel wide picture writes 6 bytes of colour and 2 bytes of padding, 8 bytes a row, and a 2 x 2 test image is exactly 70 bytes with its header. A width of 1600 needs 4,800 bytes and already lands on four, so it takes no padding at all. Add the 54-byte header and you have the file size.
Can I just rename a .jpg to .bmp instead?: No. The extension is a label and the bytes inside are still JPEG, so anything that reads the file properly will refuse it or show nothing. This tool decodes the JPEG's pixels and writes a new file that starts with the BM signature, states 24 bits a pixel and BI_RGB compression, and points at byte 54 for its pixel data. Hand it a file whose bytes are not JPEG and it names the format it actually found instead of converting.
Does converting to BMP bring back detail the JPEG lost?: No, and nothing can. JPEG throws detail away when it compresses, and a later format cannot invent it back. What you get here is a faithful, uncompressed copy of the picture as your browser decodes it today, with no further loss, rather than a restored original.
Is anything uploaded, and what are the limits?: Nothing is uploaded and there is no account. The tool opens JPEGs up to 25 MB and up to 16 million decoded pixels. Those are memory ceilings for work done inside one browser tab rather than a service limit: a 4000 by 4000 bitmap is 48,000,054 bytes on its own, and the tab has to hold both the picture and the file at once.
Can I resize the picture while I convert it?: Yes, and the aspect ratio is always kept. Set a width and the height follows it, or set a height and the width follows. A 1600 x 1200 picture asked down to 800 wide becomes 800 x 600, with a row stride of 2,400 bytes. Pixel sizes are whole numbers here, so a typed 800.5 is refused by name rather than rounded behind your back.
Will a photo taken sideways come out the right way up?: Your browser decides that, and this tool asks it to honour the EXIF orientation tag when it decodes. The panel on the left shows which tag the file carries, so you can see what was asked for. Colour management is the browser's job too. The tool reports what it found in the file and writes the pixels it was handed.
Which BMP does this write, exactly?: A 14-byte BITMAPFILEHEADER followed by the 40-byte BITMAPINFOHEADER, with one colour plane, 24 bits a pixel, BI_RGB compression, a positive height for a bottom-up pixel array, and the pixel data at offset 54. Every header integer is little-endian, and the field layout follows Microsoft's BITMAPINFOHEADER documentation for the Win32 wingdi API. The tool reads its own output back, and hands the same file to your browser's BMP decoder so the page can say it opens rather than assume it.

The BMP is written here byte for byte: a 54-byte header, 24-bit BI_RGB pixels stored bottom-up in BGR order, every row padded out to a multiple of four bytes. The pixels are whatever your browser decodes the JPEG to, so colour management and EXIF orientation are the browser's doing, and detail the JPEG already discarded does not come back. Nothing is uploaded.