Convert ICO to BMP
An .ico is not one image. It is a small archive holding several sizes of the same artwork, and the images inside it are already bitmaps — so this is closer to unpacking a folder than to converting a photograph.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your ICO file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- The largest image in the icon, chosen by pixel area
- Uncompressed 24-bit output that any Windows tooling accepts
- Opaque pixels come out byte-for-byte identical
- No watermark and no sign-up
How to use ICO to BMP
- 1
Add the .ico
An application icon, a favicon, or a file pulled out of a program's resources. Files with several sizes packed in are the normal case and are exactly what this handles.
- 2
Convert
The icon directory is read, every image inside is measured, and the one with the most pixels is written out as an uncompressed bitmap.
- 3
Check the size you received
The output dimensions tell you which image came out. If it is 48x48 and you needed the 16x16, the small one is still in the original — this picks the largest deliberately, and the smaller frames are not recoverable from the result.
How it works
The icon's directory is read first. That directory is a short table at the front of the file listing each image inside it — width, height, color depth, and where in the file its bytes begin.
Every entry is measured, the one with the greatest pixel area is selected, and its bitmap is written out with a BMP header in front of it. Transparency is composited onto white on the way, and the result is an uncompressed 24-bit file.
Measuring rather than counting matters. The images are not stored in size order, so taking the first or the last entry picks an arbitrary one.
An icon is a container, not an image
This is the thing that makes the conversion unusual: the images inside an .ico are already device-independent bitmaps — the same structure a .bmp holds, minus the file header and plus a one-bit transparency mask on older icons.
So the operation is mostly clerical. Nothing is decoded and re-encoded, no compression is applied or removed, and no quality decision exists to make. The pixels move; the wrapper changes.
That also explains a failure people hit with general-purpose image tools: handed
an icon and asked for a single-image format, many of them convert every image
inside and write out-0.bmp, out-1.bmp, out-2.bmp — then exit successfully
having produced nothing at the filename you asked for.
Where BMP is still what is wanted
Resource scripts and old build tooling. Toolchains that predate PNG support in the resource compiler take bitmaps and nothing else, and a dialog background or toolbar strip is still specified that way in a lot of long-lived codebases.
Embedded displays. Firmware with no image library reads the pixel array straight into a framebuffer. Uncompressed is the feature.
Software from the Delphi and Visual Basic era, where the component libraries were written around the bitmap and never grew past it.
If none of those describe your situation, PNG is the better extraction target — same pixels, real transparency, a fraction of the size.
Why transparency does not survive
BMP does have a 32-bit variant with an alpha channel. It is written here anyway as 24-bit with the transparency filled, because the remaining audience for BMP is software old enough to predate that variant, and such software renders the extra channel as garbage or ignores it and shows black.
An icon almost always has transparency — that is how it sits on a taskbar of any color — so this affects nearly every conversion. If you need the alpha, convert the icon to PNG instead, which keeps it exactly.
Examples
A three-size application icon
The 48 is picked because it is the largest. Scaling it down to 16 later gives a blurry result, while the 16 that was in the file was drawn for that size — so if the small one is what you need, extract it with an icon editor rather than resizing this.
A favicon from a website
The rounded corners and soft edges that were transparent are now white pixels. That is correct for the software that still consumes BMP and wrong if you were going to composite this over something — in which case PNG is the target.
Frequently asked questions
Why does an icon file contain several images?
Because Windows draws the same icon at wildly different sizes and scaling one artwork to all of them looks bad. A 16-pixel icon needs to be drawn almost like a pictogram — thick strokes, no fine detail — while a 256-pixel one can be an illustration. Packing several purpose-drawn versions into one file lets the system pick the right one instead of resizing the wrong one.
Which image do I get, and can I choose?
You get the one with the largest pixel area, and there is no picker. The largest is the only defensible default: scaling it down later is what you would have done by hand anyway, whereas upscaling a 16-pixel image to poster size is a visible mistake. Note that the largest is often neither the first nor the last image stored in the file, so it genuinely has to be measured.
Is anything lost in the conversion?
For the opaque parts, no — the pixels are copied out unchanged, because the images inside an icon are stored as bitmaps to begin with. The only thing that changes is transparency, which is composited onto white. Color values, dimensions and sharpness are exactly what was in the icon.
Why is the output so much bigger than a PNG of the same picture?
Because BMP does not compress. The file is a small header followed by the raw pixel array, three bytes per pixel, in order. A 48x30 image comes to 4,458 bytes — 48 times 30 times 3, plus a 138-byte header — and that arithmetic is essentially the entire format. It is also why software with no image library can read one.