Bitmap to Array Converter - Free Online Image to Byte Array Tool

C Array - const uint8_t

The standard C array format produces a const uint8_t declaration suitable for any C or C++ project targeting microcontrollers including AVR (Arduino Uno, Nano, Mega), ARM Cortex-M (STM32, nRF52, RP2040), RISC-V, and PIC. This format works with any display library that accepts a raw byte pointer. The array is placed in RAM by default; move it to flash using your toolchain's specific flash-placement attribute if RAM is limited.

const uint8_t my_image[] = {
  0xFF, 0x81, 0x81, 0x81, 0xFF, ...
};
const uint16_t my_image_width  = 128;
const uint16_t my_image_height = 64;

Arduino PROGMEM - Flash Memory Storage

The Arduino PROGMEM format stores the array in flash (program memory) instead of SRAM. On AVR-based boards - Arduino Uno, Nano, Mega, Leonardo - SRAM is extremely limited (2 KB on the Uno). A 128x64 bitmap at 1 bpp occupies 1,024 bytes, which would consume half the Uno's entire RAM. Using PROGMEM keeps it in flash, preserving SRAM for runtime variables. This format is also commonly used with Adafruit GFX, U8g2, and Adafruit SSD1306 libraries. ESP32 and ESP8266 boards support PROGMEM for compatibility, though they have far more RAM available.

const unsigned char my_image[] PROGMEM = {
  0xFF, 0x81, 0x81, 0x81, 0xFF, ...
};
// Usage with Adafruit SSD1306:
display.drawBitmap(0, 0, my_image, 128, 64, WHITE);

Rust Static Byte Array - Embedded Rust

The Rust output format generates a static byte slice suitable for embedded Rust projects using the embedded-hal ecosystem,embassy, rtic, or bare-metal no_stdenvironments. The array is placed in flash memory at link time. This format works with Rust display drivers such as embedded-graphics,ssd1306, ili9341, st7735-lcd, andepd-waveshare crates.

pub static MY_IMAGE: &[u8] = &[
    0xFF, 0x81, 0x81, 0x81, 0xFF,
    // ...
];
pub const MY_IMAGE_WIDTH: u32 = 128;
pub const MY_IMAGE_HEIGHT: u32 = 64;

Hex String - Raw Hexadecimal Output

The hex string format outputs the raw image data as a continuous hexadecimal string without any language-specific wrapper. This is useful for custom parsing scripts, Python tools, MicroPython firmware, or when feeding data into a proprietary build system, binary patching tool, or memory flashing utility that ingests raw hex input.

Grayscale Reduction

All input images - regardless of whether they are RGB, RGBA, or already grayscale - are first converted to a grayscale luminance map. The standard luminance formula (0.299R + 0.587G + 0.114B) weights the green channel more heavily because human vision is most sensitive to green wavelengths. The resulting per-pixel values range from 0 (black) to 255 (white).

Quantization and Thresholding

Each grayscale pixel is then quantized to the target bit depth. For 1 bpp, pixels at or above the threshold (typically 128) become white (1) and those below become black (0). For 2 bpp, the 0–255 range is divided into four equal bands mapped to values 0–3. For 4 bpp, it is divided into 16 bands (0–15). For 8 bpp, the 8-bit grayscale value is used directly.

Floyd-Steinberg Error Diffusion

When dithering is enabled, quantization error (the difference between the original pixel value and the quantized output value) is distributed to neighboring pixels using the Floyd-Steinberg weights: 7/16 to the right, 3/16 to the lower-left, 5/16 directly below, and 1/16 to the lower-right. This creates a natural-looking dithered pattern that preserves the perceived tonal range of the original image on low bit-depth displays. It is strongly recommended for photographic source images being converted to 1 bpp for OLED or e-ink output.

Pixel Packing into Bytes

After quantization, pixels are packed into bytes. For 1 bpp, eight horizontally adjacent pixels share a single byte. With MSB-first packing, the leftmost pixel occupies bit 7 (the most significant bit) and the rightmost pixel occupies bit 0. With LSB-first packing, the order is reversed. Row padding is applied as needed to align each row to a byte boundary. For 2 bpp, four pixels share a byte; for 4 bpp, two pixels share a byte; for 8 bpp, each pixel occupies a full byte.

Array Size Calculation

The number of bytes in the output array can be calculated as:bytes = ceil(width / (8 / bpp)) * height. For example, a 128x64 image at 1 bpp producesceil(128 / 8) * 64 = 16 * 64 = 1,024 bytes. At 8 bpp, the same image produces 128 * 64 = 8,192 bytes. Always verify that the output array size fits within your target microcontroller's available flash and RAM constraints before integrating it into your project.

Resize Your Image Before Converting

Always resize your source image to match your display's resolution before uploading. For a 128x64 OLED, resize to exactly 128x64 pixels in an image editor such as GIMP, Photoshop, or Inkscape. Scaling inside the converter may not apply the optimal interpolation algorithm for your use case.

Use PNG for Monochrome Source Images

JPEG compression introduces block artifacts and noise that degrade 1 bpp conversion quality significantly. Always use PNG (lossless) for monochrome icons, logos, and geometric shapes. If your source is a JPEG photograph, enabling Floyd-Steinberg dithering will produce better results than simple thresholding.

Check MSB vs LSB if Your Image Appears Mirrored

If the output on your physical display appears horizontally scrambled or mirrored - with correct overall shape but pixels shifted or reversed within each byte - toggle the bit order setting between MSB-first and LSB-first. This is the most common source of display rendering errors when integrating new display controllers.

Calculate Flash Usage Before Integrating

An Arduino Uno (ATmega328P) has 32 KB of flash. A 128x64 image at 1 bpp occupies 1 KB. Ten such images occupy 10 KB - nearly a third of the available flash. For image-heavy projects, consider using an Arduino Mega (256 KB flash), ESP32 (4 MB flash), or storing images on an external SPI flash or SD card.

Invert Colors for OLED Displays

Most OLED displays (SSD1306, SH1106) default to a black background with white pixels. If your source image has a white background with black content, invert the image in your editor before converting, or use the invert function in your display library. This avoids driving the full OLED panel white, which consumes maximum current and reduces OLED lifespan.

Organize Multiple Images in a Single Header File

For projects using several bitmap assets, place all converted arrays in a single images.h file with include guards. Use a consistent naming convention such as img_wifi_icon_16x16 to encode the asset name and dimensions, making it easy to locate and update individual assets as the project evolves.

What bit depth should I use for my display?

Use 1 bpp for monochrome displays: SSD1306 OLEDs, SH1106 OLEDs, Waveshare e-ink, Nokia 5110 LCD, KS0108 GLCD. Use 2 bppfor 4-gray-level displays such as the SSD1325. Use 4 bppfor 16-level grayscale controllers. Use 8 bpp for displays or frame buffers that support 256-level grayscale. For full RGB color displays (ILI9341, ST7789), you need a 16-bit RGB565 converter rather than this grayscale bit-packed converter.

Why does my image look wrong on the display?

The four most common causes are: (1) incorrect bit order - toggle between MSB and LSB; (2) incorrect row order - toggle between top-to-bottom and bottom-to-top; (3) the image dimensions do not match what was passed to the draw function - double-check width and height constants; (4) the image data is placed in SRAM but your draw call reads from PROGMEM or vice versa. Most Adafruit libraries have separate versions of draw functions for RAM and PROGMEM buffers.

Is this tool free for commercial use?

Yes. The generated array output - C code, PROGMEM declarations, Rust code, hex strings - is yours to use in any project, whether personal, open-source, or commercial. There are no licensing restrictions on the tool's output.

Is my image data private? Does it get uploaded?

All processing happens entirely in your browser using JavaScript. Your images are never uploaded to any server. The tool works fully offline once the page has loaded. This makes it safe to use with proprietary product logos, confidential UI assets, and sensitive firmware graphics.

How do I use the generated array with Adafruit GFX?

Select the "Arduino PROGMEM" output format and copy the generated code into a .h header file. Include that file in your sketch. Then call display.drawBitmap(x, y, myArray, width, height, WHITE)from the Adafruit SSD1306 or Adafruit GFX library. Make sure the width and height arguments match the actual dimensions of your converted image.

How do I use the output with U8g2?

U8g2 uses the u8g2.drawXBM() or u8g2.drawBitmap()functions depending on the byte layout. For the horizontal byte layout (which this tool produces), use drawBitmap(). If usingdrawXBM(), note that XBM format uses LSB-first bit ordering, so select LSB-first in this converter to match.

Can I convert a 128x64 image for an SSD1306 OLED?

Yes. Resize your image to exactly 128x64 pixels in an image editor, upload it here, select 1 bpp, choose MSB-first bit order, enable Floyd-Steinberg dithering if it is a photograph, select Arduino PROGMEM format, and copy the output. The result will be a 1,024-byte PROGMEM array ready for use with any SSD1306 Arduino library.

What is the difference between MSB-first and LSB-first?

In MSB-first packing, the leftmost pixel in a row is placed in bit 7 of the first byte. In LSB-first packing, the leftmost pixel is placed in bit 0. Adafruit GFX, most SSD1306 libraries, and U8g2 drawBitmap use MSB-first. XBM format and some ST7565 implementations use LSB-first. If pixels in your rendered image appear scrambled within groups of 8, toggle this setting.

Does this tool support color images for TFT displays?

This converter specializes in grayscale packed-pixel formats (1/2/4/8 bpp) suited for monochrome and grayscale displays. For RGB565 color output needed by ILI9341, ST7789, or ST7735 TFT displays with libraries like TFT_eSPI, a 16-bit RGB converter is more appropriate. The 8 bpp output from this tool can be used as a grayscale layer for some TFT rendering pipelines.

Can I use this to generate images for Waveshare e-ink displays?

Yes. Waveshare e-paper libraries (both Arduino and Raspberry Pi variants) accept 1 bpp packed byte arrays. Convert your image with 1 bpp, MSB-first, top-to-bottom row order, and download the .h header. Include it in your project and pass the array pointer to theEPD_Display() or equivalent function. For 3-color (black/white/red or black/white/yellow) panels, you need two separate arrays - one for black pixels and one for the color layer.