If I have both a JPG and a PNG of the same image, which should I produce the BMP from?

Produce it from the PNG. Because PNG is lossless, it contains none of JPG's compression artefacts; the resulting BMP carries cleaner pixel data. If you go via the JPG, ringing, blocking and edge softening are carried into the BMP exactly as they are and become permanent. Even if the two files look similar on screen, there is a difference at the pixel level, and that difference is especially visible in images containing text, lines and sharp edges.

My device won't accept the BMP even though the format is right. Why?

The problem is most likely the variant rather than the format. BMP is not a single uniform structure; it can be produced at different bit depths such as 24-bit, 32-bit and indexed 8-bit, and older systems often accept only one of them. Many embedded devices also expect a fixed resolution and reject files of a different size. Check the device's documentation for the expected bit depth and pixel dimensions; when those do not match, even a valid BMP can be rejected.

What should I do if I need to convert an image containing transparency to BMP?

First find out what the target system will do with transparency. BMP's 32-bit variant can carry an alpha channel, but that support is inconsistent across applications and many readers ignore the alpha byte. In that case transparent areas are filled with a solid colour, and which colour that is can vary from reader to reader. The safest method is to deliberately fill the background with the colour you want and remove the transparency yourself before converting; that way you leave nothing to chance.

Does the number of steps in a conversion chain cause problems?

What matters is the number of lossy steps in the chain, not the total number of steps. You can move between lossless formats as much as you like; going from PNG to BMP and back to PNG does not change the image. Every JPG save, by contrast, adds a new layer of degradation. So if your chain contains more than one JPG step, that is where the problem lies. Where possible, produce the BMP in a single step from the lossless file closest to the source.

Which Route Should You Take for Programs That Demand BMP Output?

Framing the question correctly

Sometimes you have no choice. A production line panel, an old Windows program, a CAD import tool or a device's splash screen accepts only BMP and there is no negotiating. In that case the question is not "should I convert to BMP" but "what should I produce the BMP from".

Because there is more than one route to BMP, and which one you take directly affects the result. This article compares that decision.

The critical point: BMP carries the source, it does not improve it

Before moving to the comparison, let's establish the basic rule, because everything rests on it.

BMP is an uncompressed format and it stores the pixel data it is given exactly as it is. It does not fix the content, sharpen it or clean up artefacts. Your BMP file's quality is entirely the source's quality.

The practical meaning of this: the source choice is the only real decision in this conversion. There is no quality slider to adjust in the conversion itself; what decides the outcome is what you feed in.

Route 1: JPG to BMP

This is the most common scenario, because most of the images we have are already JPG.

What happens: The JPG is decoded and the pixel data is written raw into the BMP container. No new loss occurs at this step — because there is nothing left to lose. The moment the JPG was saved, the compression algorithm had already discarded the information the eye barely notices.

The result: All of your JPG's flaws are carried into the BMP exactly as they are. Ringing around sharp edges, blocking in flat gradients, softening in fine textures — all of it is there, and now stored uncompressed.

When it is acceptable: When JPG is your only source and the target system will simply display the image. For a splash screen, an interface graphic or a preview, this is usually sufficient.

When it causes problems: When the image contains text, fine lines or sharp contours. JPG artefacts are visible in this kind of content and become permanent in the BMP. And if automated analysis or measurement will be performed on the image, the artefacts change pixel values and can affect the results.

Route 2: PNG to BMP

If a PNG version of the same image exists, or you can go back to the source and produce one, this should be your choice.

What happens: PNG is a lossless format; the pixel data inside it has been preserved exactly as it was at the moment of saving. That data is written straight into the BMP.

The result: The resulting BMP carries cleaner pixel data than the BMP produced via the JPG route. The two files may look similar on screen, but there is a difference at the pixel level, and it is especially visible in text and sharp edges.

The only thing to watch is transparency. PNG carries the alpha channel reliably; BMP may not. We have given that topic its own section below.

Comparison summary

| Criterion | BMP from JPG | BMP from PNG | | --- | --- | --- | | Pixel accuracy | Source artefacts made permanent | Source data one-to-one | | Text and sharp edges | Ringing carried over | Clean | | Suitability for measurement/analysis | Risky | Suitable | | Transparency | Already absent | Can be lost, needs checking | | Resulting file size | Same | Same |

That last row is worth noting: BMP's size does not depend on the source at all. If the resolution and bit depth are the same, both routes produce a file of the same size. So going via JPG does not even have a size advantage — it only has a quality disadvantage.

The transparency trap

This is the most common problem when going via PNG.

BMP's 32-bit BGRA variant can hold an alpha channel, but support for it is inconsistent across applications. Many readers ignore the alpha byte entirely and display transparent areas as opaque. Which colour they are filled with varies by reader; it is usually white or black, but that cannot be relied on.

If an old device or program is involved, assuming there is no alpha support is the safest approach.

The solution is simple: deliberately fill the background with the colour you want before converting. If a logo will be shown on a dark panel, make its background that dark colour. That way you leave nothing to chance and get exactly the image you expect on the target system.

Bit depth: the real reason for rejections

The complaint "the file is a valid BMP but the device won't accept it" almost always comes down to this.

BMP is not a single uniform structure. It has variants such as 24-bit, 32-bit and indexed 8-bit, and older systems can often read only one of them. Many embedded devices also expect a fixed resolution; they reject a file of the wrong size or display it incorrectly.

Before converting, look for these two things in the target system's documentation: the expected bit depth and the expected pixel dimensions. When those two do not match, you will get nowhere even if the format is correct.

The practical decision

The order is clear:

If you have a lossless source, start there. The original editing file, a PNG copy or a lossless scan — whichever you have will give the cleanest result.
If you only have a PNG, go from the PNG. Sort out the transparency situation beforehand.
If you only have a JPG, go from the JPG. Converting JPG to BMP does the job; just know that the source's flaws become permanent.
Do not let the chain contain more than one JPG step. You can move between lossless formats as much as you like, but every JPG save adds a new layer of degradation.

In summary

On the road to BMP, the conversion itself is not what decides the outcome; the source is. Go in a single step from the most lossless source available, find out the target system's bit-depth and resolution expectations beforehand, and flatten transparency yourself instead of leaving it to chance. Do those three things and you eliminate most of the surprises you would otherwise face when dealing with an old system.