Image to byte array converter online

A microcontroller can't open a PNG. It has no image decoder and usually no file system, so the picture has to live inside your sketch as numbers. That list of numbers is the byte array. How the numbers are laid out depends on the screen and the library, and getting the layout wrong is the reason most converted images look like static.

On a monochrome OLED such as the SSD1306 or SH1106, every pixel is either on or off. That's one bit, so one byte holds eight pixels. The converter first turns your image into pure black and white with a threshold: any pixel brighter than the threshold becomes a lit pixel. Then it packs the bits into bytes.

Size: why 128×64 is always 1,024 bytes

128 × 64 = 8,192 pixels. Eight pixels per byte gives 8,192 ÷ 8 = 1,024 bytes. A 128×32 bar display is 512 bytes, and a 72×40 screen is 360 bytes. When a row isn't a multiple of eight, it's padded: a 10-pixel-wide image still takes two bytes per row. If your array is a different length from what you expect, the canvas size is wrong.

Horizontal order (Adafruit GFX, image2cpp)

Adafruit's drawBitmap() reads the image row by row. Each byte is eight pixels across, and the leftmost pixel is the highest bit (bit 7). An 8×8 hollow square is eight bytes:

// 8x8 outline, horizontal, MSB = left pixel
const unsigned char box[] PROGMEM = {
  0xFF, 0x81, 0x81, 0x81, 0x81, 0x81, 0x81, 0xFF
};
display.drawBitmap(60, 28, box, 8, 8, SSD1306_WHITE);

The top and bottom rows are all on (0xFF). The middle rows only have the two edge pixels on, which is 10000001 in binary, or 0x81. MicroPython's framebuf.MONO_HLSB uses the same layout.

XBM order (U8g2)

U8g2's drawXBMP() also reads rows, but the leftmost pixel is the lowest bit (bit 0). The hollow square happens to look the same, but a single pixel in the top-left corner is 0x80 for Adafruit and 0x01 for XBM. Feed an Adafruit array to U8g2 and every group of eight pixels comes out mirrored.

Vertical page order (SSD1306 native)

Inside the SSD1306 the screen memory is split into pages that are eight rows tall. Each byte is a column of eight pixels, with the top pixel in bit 0. A 128×64 screen has eight pages of 128 bytes. The Adafruit library keeps its buffer in this order too, so a full-screen frame in page order can be copied straight into display.getBuffer(). MicroPython calls this layout MONO_VLSB, and it's what the ssd1306 driver uses internally.

SH1106 has 132 columns

SH1106 modules look identical to SSD1306 ones, but the chip has 132 columns of memory and the glass shows the middle 128. If you write raw page data starting at column 0, the picture shifts two pixels and the right edge wraps. Libraries that support SH1106, such as U8g2 and Adafruit SH110X, add the offset for you. That's why the converter's sketch option uses those libraries when you pick SH1106.

PROGMEM and memory

An Arduino Uno has 32 KB of flash but only 2 KB of RAM. A single 1,024-byte frame would eat half the RAM, so the array is marked PROGMEM and stays in flash. ESP32, ESP8266 and RP2040 boards have far more memory, and PROGMEM is harmless there. The converter shows the byte count and warns you when an image won't fit on an Uno.