About

The BMP (Bitmap) file format stores pixel color data in BGR byte order, not the RGB order that most rendering pipelines and image editors expect. Loading a BGR-ordered buffer into an RGB-expecting context produces images with swapped red and blue channels. Skin tones turn blue. Skies turn orange. The error is silent and systematic. This tool performs a direct byte-level swap of the first and third channel bytes in every pixel triplet (or quad for 32-bit), operating on the raw binary data without re-encoding or lossy compression. It handles DWORD row padding, bottom-up scanline order, and both 24-bit and 32-bit pixel depths. Processing is entirely client-side; your files never leave the browser.

This tool assumes uncompressed BMP files (BI_RGB compression, type 0). RLE-compressed or OS/2 variant BMPs are rejected with a diagnostic message. The output file preserves the original header metadata exactly; only the pixel data bytes are modified. Note: if your source file is already in RGB order (non-standard for BMP), running this converter will incorrectly swap it to BGR. Verify your source channel order before converting.

Formulas

The channel swap operates on each pixel in the raw byte buffer. For a 24-bit uncompressed BMP, the pixel data begins at byte offset O (read from header at 0x0A). Each scanline contains W pixels of 3 bytes each, padded to the nearest 4-byte boundary.

P = (4 − (W × bpp) mod 4) mod 4

Where P = padding bytes per row, W = image width in pixels, and bpp = bytes per pixel (3 for 24-bit, 4 for 32-bit). The stride (total bytes per row) is:

S = W × bpp + P

For each pixel at row r, column c, the byte index into the pixel data region is:

i = O + r × S + c × bpp

The swap operation exchanges byte[i] (Blue) with byte[i + 2] (Red). The green channel at byte[i + 1] and alpha at byte[i + 3] (32-bit only) remain untouched.

temp = buf[i]
buf[i] = buf[i + 2]
buf[i + 2] = temp

Reference Data

BMP Property	Header Offset	Size (bytes)	Description
Magic Number	0x00	2	Must be 0x42 0x4D ("BM")
File Size	0x02	4	Total file size in bytes
Reserved	0x06	4	Application-specific; usually 0
Pixel Data Offset	0x0A	4	Byte offset to start of pixel array
Header Size	0x0E	4	DIB header size (40 for BITMAPINFOHEADER)
Image Width	0x12	4	Width in pixels (signed int32)
Image Height	0x16	4	Height in pixels (negative = top-down)
Color Planes	0x1A	2	Must be 1
Bits Per Pixel	0x1C	2	1, 4, 8, 16, 24, or 32
Compression	0x1E	4	0 = BI_RGB (uncompressed)
Image Data Size	0x22	4	Size of raw pixel data (may be 0 for BI_RGB)
H Resolution	0x26	4	Pixels per meter (horizontal)
V Resolution	0x2A	4	Pixels per meter (vertical)
Colors Used	0x2E	4	Number of palette colors (0 = default)
Important Colors	0x32	4	Number of important colors (0 = all)
Pixel Byte Order by Bit Depth
24-bit BGR	3 bytes/pixel		B₀ G₁ R₂ → R₀ G₁ B₂
32-bit BGRA	4 bytes/pixel		B₀ G₁ R₂ A₃ → R₀ G₁ B₂ A₃
Row Padding	0-3 bytes		Each row padded to 4-byte (DWORD) boundary
Scanline Order	-		Bottom-up if height > 0; top-down if < 0

Frequently Asked Questions

The BMP format was designed by Microsoft for Windows GDI, which internally uses COLORREF values stored as 0x00BBGGRR in little-endian DWORD format. When read byte-by-byte from low address to high, this yields Blue first, then Green, then Red. This is a direct consequence of x86 little-endian architecture and the Windows API convention, not a deliberate design choice for image quality.

The converter performs a blind byte swap of position 0 and position 2 in each pixel group. If your file is already in RGB order (which is non-standard for BMP), the output will have swapped Red and Blue channels, effectively converting it to BGR. The operation is its own inverse: running it twice on any file restores the original byte order.

No. This tool only processes uncompressed BMP files with BI_RGB compression type (value 0 at header offset 0x1E). RLE4 (type 2) and RLE8 (type 1) compression use run-length encoding that requires decompression before channel manipulation. Indexed-color BMPs (1-bit, 4-bit, 8-bit) store palette indices rather than direct color values, so channel swapping must target the palette table, not the pixel data. These variants are rejected with a specific error message.

No. The output file is byte-identical in size to the input. Only pixel data bytes are modified in place. The BMP header, padding bytes, and overall file structure remain unchanged. The conversion is lossless and deterministic.

BMP scanlines must be DWORD-aligned (multiples of 4 bytes). For a 24-bit image of width 5 pixels, each row is 15 bytes of pixel data plus 1 byte of padding, totaling 16 bytes. If the converter ignores padding and treats pixel data as a flat stream, it will eventually swap a padding byte with a color byte, causing a cascading 1-pixel color shift that worsens with each subsequent row. This tool calculates padding per the formula P = (4 − (W × bpp) mod 4) mod 4 and skips padding bytes during iteration.

Yes. For 32-bit BMPs, each pixel is stored as BGRA (4 bytes). The converter swaps byte 0 (Blue) with byte 2 (Red), leaving byte 1 (Green) and byte 3 (Alpha) untouched. The result is RGBA order. Note that 32-bit BMP rows have no padding since 4 × W is always divisible by 4.