Convert BMP to JPG
Re-encode a BMP as a JPEG, which is the right move for a photograph and the wrong one for a screenshot.
How it works
A BMP stores its pixels almost exactly as a decoder would hand them over, row after row, so the file is large by construction. That is the whole of the format's contribution here, and the BMP to PNG converter covers the rest of it. What matters before converting is what the picture contains. JPEG was specified in 1992 for continuous-tone photographs and on that material it earns its reputation. On flat colour with sharp boundaries it does visible damage and, measured on a real screenshot further down, produces a file two and a half times larger than the lossless alternative.
What JPEG was built to throw away
A photograph goes into the encoder in 8×8 blocks, each block becomes a set of frequency coefficients, and the high ones are quantised hardest. In a photograph those coefficients mostly describe sensor grain and fine texture that the eye weights lightly, so discarding them costs little anybody can see. A photograph is otherwise mostly gradient, which the low coefficients already describe well.
Measured in this session on a 640×426 photographic BMP of 818,058 bytes: quality 85 produced 78,141 bytes at a mean absolute error of 3.91 out of 255 per channel, while a lossless PNG of the identical pixels came to 484,922 bytes. The JPEG is 6.2 times smaller than the exact version of the same picture.
Ringing, and why text is where you see it
A step edge, black text against white, carries energy at every frequency the transform can represent and some at frequencies it cannot. Reconstructing that edge from a truncated series overshoots on both sides of it, which is the Gibbs phenomenon. In a picture the overshoot appears as a faint halo of alternating light and dark pixels running parallel to the boundary.
Measured on a 640×426 screenshot holding black body text, a solid blue panel and a bordered table: at quality 85, pixels that were pure white in the source and surrounded by pure white came back as low as 221. At quality 95 the worst of them still read 232. Quality does not remove the halo, it only narrows the amplitude.
Colour fares worse. Baseline JPEG samples chroma at half resolution in each direction, so a coloured letterform gets a quarter as many colour samples as it gets brightness samples. The red text in that screenshot, a uniform #d40000 in the source, came back with individual channels off by as much as 104 out of 255. Nobody sees this during the conversion. They see it a week later at 100% zoom, and by then the BMP has usually been deleted.
The rule
Photographic content to JPEG. Anything with flat regions and hard edges to PNG, which encodes a run of identical pixels almost for free and returns every one of them exactly. The screenshot is the whole argument: 11,685 bytes as a PNG against 28,723 bytes as a quality-85 JPEG with the ringing described above. Scans, old digital camera output and anything a flatbed produced take the first path. Screenshots, diagrams, logos and charts take the second, and the BMP to PNG converter is the page for those.
The 32-bit form and its alpha
A 32-bit BMP carries a fourth byte per pixel. Under the original BITMAPINFOHEADER that byte is undefined; BITMAPV4HEADER, added in Windows 95, gave it a declared alpha mask, and a file written that way holds real transparency. JPEG has nowhere to keep it, since ITU-T T.81 describes a frame as one to four components with no notion of opacity. Every non-opaque pixel is therefore composited onto the background colour selected above, blended in proportion to its alpha so a soft edge stays soft, and the result line states whether any compositing happened.
Only one direction
A BMP is lossless, so nothing done to it up to this point has closed a door. The JPEG closes one. The quantised coefficients are gone, the composited background cannot be lifted back off, and saving that JPEG as a PNG afterwards preserves the artifacts perfectly rather than removing them. Keep the BMP while it is the only original you hold. The decode, the composite and the mozjpeg encode all run as WebAssembly inside a Web Worker on your own machine, with no queue and no daily conversion limit.
Questions
Does the file get sent anywhere?
No. Open developer tools before you convert, leave the Network tab visible, and read the origin column: every entry is this site's own script and WebAssembly. Your BMP is in none of them, and no request body carries it. The bytes are read into memory by the browser and passed to a Web Worker on the same machine.
Why does the default sit at 85?
Because that is where the curve bends on the photograph measured for this page. Quality 82 gave 69,187 bytes at a mean absolute error of 4.93 out of 255, quality 85 gave 78,141 bytes at 3.91, and quality 90 spent a further 40% of the bytes to reach 2.72. A BMP is a first-generation original, so this encode is the only loss the picture will ever take, and 85 buys the last improvement anyone will notice before size climbs faster than fidelity.
My converted screenshot looks fuzzy around the letters. Can I fix it?
Not by raising the quality. The measurement on this page found flat white pixels reading 221 at quality 85 and 232 at quality 95, so the halo shrinks and never leaves. Convert the BMP to PNG instead: on the screenshot measured here PNG came to 11,685 bytes against the JPEG's 28,723, so it is exact and smaller at once.
What happens to transparency in a 32-bit BMP?
It is blended onto white or black, whichever you select, and every pixel then becomes opaque. Semi-transparent pixels are mixed in proportion to their alpha, so an anti-aliased outline keeps its smooth edge rather than developing a fringe. Exercised on a 256×256 32-bit BMP with a BITMAPV4HEADER alpha mask and 2,860 non-opaque pixels out of 65,536, the result line reported the composite.