About

Raw BGRA pixel data is a headerless binary format where each pixel occupies 4 bytes in Blue - Green - Red - Alpha order. Without embedded metadata, the file carries zero information about image dimensions or color space. Feed the wrong width to a naive reader and every scanline shifts, producing diagonal garbage. This tool performs real byte-level channel remapping (B ↔ R) and rasterizes the corrected RGBA buffer onto a canvas for native JPEG compression. You must supply the correct width and height because the converter validates that filesize ≥ W × H × 4 bytes before proceeding.

JPEG quality maps to the lossy DCT quantization tables inside the browser's encoder. A quality of 0.92 is visually lossless for photographic content. Below 0.50, chroma sub-sampling artifacts become visible on sharp edges. Note: JPEG discards the alpha channel entirely. If your source relies on transparency, the alpha data will be composited against a white background before encoding.

Formulas

The raw BGRA file size must satisfy the dimensional constraint before conversion can proceed:

FileSize ≥ W × H × 4

where W = image width in pixels, H = image height in pixels, and 4 = bytes per pixel (BGRA).

Channel remapping for each pixel index i (offset = i × 4):

R_out = B_in , G_out = G_in , B_out = R_in , A_out = A_in

In byte terms at offset o: swap byte[0] (Blue) with byte[2] (Red). Bytes at positions [1] and [3] remain unchanged.

Alpha compositing against white before JPEG encoding (since JPEG lacks alpha):

C_final = C_src × A255 + 255 × (1 − A255)

where C_src is the source channel value (0-255), A is the alpha byte, and the background is white (255).

Reference Data

Property	BGRA (Raw)	JPEG (Output)
Header	None (headerless)	SOI + APP0/EXIF markers
Channel Order	B, G, R, A	Y, Cb, Cr (YCbCr)
Bits per Pixel	32	Variable (lossy)
Bytes per Pixel	4	N/A (compressed)
Alpha Support	Yes (byte 3)	No
Compression	None	DCT-based lossy
Typical File Size (1920×1080)	8,294,400 bytes (exact)	100-500 KB
Endianness	Little-endian (x86 native)	Big-endian (JFIF)
Max Dimensions (Browser)	Limited by RAM	16384 × 16384 px (canvas limit)
Color Depth	8 bit/channel	8 bit/channel
Use Case	Frame buffers, GPU textures, DirectX	Web, photography, sharing
Quality 1.0	-	~95% original fidelity
Quality 0.8	-	~85% fidelity, ~60% size reduction
Quality 0.5	-	~70% fidelity, visible artifacts
Quality 0.1	-	Heavy blocking, chroma smear
MIME Type	application/octet-stream	image/jpeg
Common Extensions	.bgra, .raw, .data, .bin	.jpg, .jpeg

Frequently Asked Questions

Divide the file size in bytes by 4 to get total pixel count. Then factor that count into plausible dimensions. For example, a 8,294,400-byte file contains 2,073,600 pixels, which factors to 1920 × 1080. If your file came from a frame buffer or screen capture, the dimensions usually match the display resolution. The tool shows you the expected file size so you can verify your inputs before converting.

JPEG does not support transparency. The converter composites semi-transparent pixels against a white background using standard alpha blending: C_final = C × (A/255) + 255 × (1 − A/255). Fully transparent pixels become white. If preserving transparency matters, consider converting to PNG instead.

This is the classic sign of an incorrect width value. When width is wrong, each scanline starts at the wrong byte offset, causing pixels to shift diagonally. Verify that W × H × 4 exactly equals your file size. Even being off by one pixel in width will produce the stripe artifact.

Browser canvas elements are typically limited to 16384 × 16384 pixels, though some browsers cap total pixel count at around 268 million. For practical purposes, images up to 8192 × 8192 convert reliably across all modern browsers. Very large buffers may also be constrained by available system RAM.

JPEG quality controls the DCT quantization step. At quality 1.0, quantization is minimal, preserving detail but producing larger files (often 10-20× smaller than raw BGRA). At 0.8, files shrink an additional 40-60% with barely perceptible loss. Below 0.5, blocking artifacts appear in smooth gradients and ringing artifacts emerge near sharp edges. For photographic content, 0.85 - 0.92 is the standard sweet spot.

No. The entire conversion runs locally in your browser using the Canvas API. Your binary data never leaves your device. The file is read into an ArrayBuffer via the FileReader API, channel-swapped in JavaScript, painted to an in-memory canvas, and encoded to JPEG by the browser engine. No network requests are made during conversion.