Instantly convert C arrays, Rust byte arrays, hex dumps, and .bin files into a visual image preview. Supports 1 bpp, 2 bpp, 4 bpp, and 8 bpp packed pixel formats. Perfect for Arduino, ESP32, OLED, TFT, and embedded LCD projects.
An array to image converter is a developer utility that takes a raw byte array - typically a C-style uint8_t[] or Rust &[u8] - and reconstructs it into a pixel image you can see in your browser. When you write firmware for an embedded display like an SSD1306 OLED, an ILI9341 TFT, an ST7735 screen, or a custom monochrome LCD, you almost always store graphics as packed hex arrays inside your source code. Debugging those arrays is painful without a visual preview, and that is exactly what this tool solves.
Unlike generic image viewers, this byte array to image tool understands the specific packing schemes used in embedded graphics libraries such as Adafruit GFX, u8g2, LVGL, and TFT_eSPI. It lets you configure bits-per-pixel depth, MSB-first or LSB-first bit ordering, and top-down or bottom-up row order - all in real time - so you can match the exact format your display driver expects.
Everything runs entirely in your browser. No files are uploaded to any server. The tool works offline once the page has loaded, which matters when you are working in a lab with spotty internet connectivity.
Paste arrays in any common format. The parser automatically strips C-style block comments (/* */), line comments (//), Rust pub const declarations, brackets, and semicolons. It accepts 0xFF token syntax, bare two-digit hex tokens like FF, and plain contiguous hex strings with no delimiters. Whether you copy directly from an Arduino .h header, a Rust include_bytes! block, or a hex editor, it just works.
1-bit-per-pixel is the format used by virtually every OLED display library including Adafruit SSD1306, u8g2, and U8x8. Each byte encodes 8 horizontal pixels. With MSB-first ordering (the default for most OLED drivers), bit 7 of the first byte is the leftmost pixel in the row. Flip to LSB-first to match older display protocols or custom framebuffers. This tool renders your OLED bitmap array as a crisp monochrome image so you can verify it before flashing to hardware.
Some displays - particularly e-ink panels and certain OLED variants - use 2-bit (4-level) or 4-bit (16-level) grayscale. This tool correctly unpacks both formats, mapping index values to evenly spaced gray levels. Use it to preview grayscale byte arrays from SparkFun flexible OLEDs, Sharp Memory LCDs, or any 4-bit GLCD framebuffer before you commit to hardware.
Full 8-bit grayscale arrays are common in TFT splash screens, e-paper displays, and firmware-stored image assets. At 8 bpp each byte is one pixel, giving 256 gray levels. Combine this with the custom color picker to map those gray levels to any two colors - ideal for previewing PROGMEM bitmap arrays for Arduino TFT projects using the TFT_eSPI or MCUFRIEND_kbv libraries.
Bit endianness is the single most common source of "scrambled" images on embedded displays. If your image looks like random noise or a mirrored mess, try toggling between MSB-first and LSB-first. MSB-first is standard for most OLED and LCD bitmap arrays. LSB-first is used by some older GLCD libraries and certain Bluetooth/display protocols. This toggle lets you find the correct bit order in one click without writing any code.
Standard BMP files store rows from bottom to top - a legacy of early Windows GDI conventions. Most OLED and TFT framebuffers store rows top-down. If your image appears vertically flipped, simply switch the Row Order toggle from "Top → Bottom" to "Bottom → Top." This is also useful when reverse-engineering arrays from firmware images where the row order is unknown.
Beyond plain monochrome, the tool offers five built-in color presets: classic black-and-white, warm Sepia, retro Amber (like an old VFD or CRT terminal), cool Ice, and technical Blueprint. Each preset remaps the grayscale gradient to a two-color range you can fully customize with the color pickers in Custom mode. Brightness, contrast, and gamma sliders apply in real time, letting you simulate the actual visual appearance of your embedded display.
Not all pixel data lives in source files. Firmware binary blobs, raw SPI captures, and memory-mapped frame buffers often come as binary .bin files. Drag and drop any .bin file onto the drop zone - the tool reads it with the Web File API and populates the hex display automatically, so you can visualize raw memory dumps from embedded systems, logic analyzer captures, or flash dumps without any conversion step.
Toggle an 8×8 pixel grid over the preview to count and inspect individual pixels - essential when debugging custom fonts or small icon sprites for constrained displays like the 128×32 SSD1306.
Download the rendered image as a PNG file, sized at the exact pixel dimensions of your array. Use it in project documentation, datasheets, pull request screenshots, or to compare against reference images from your display driver.
If your array includes a comment in the format // width: 128, height: 64 (generated by tools like image2cpp), the tool parses and applies those dimensions automatically, saving you from having to enter them manually.
Follow these steps to go from a raw C or Rust pixel array to a visual image preview:
.h header, your Rust source file, a hex editor, or a logic analyzer export. Paste it directly into the Array Text box. Alternatively, drag a .bin file onto the drop zone or click "Choose .bin." The parser will strip any surrounding C/Rust syntax automatically.width: X, height: Y the tool fills these in automatically.Arduino sketches and ESP32 firmware commonly store splash screens, icons, and UI elements as PROGMEM const uint8_t[] arrays. Converting these with tools like image2cpp is straightforward, but verifying the output - especially when the bit order or row direction is wrong - requires flashing the device, which costs time. This tool lets you verify the array visually in seconds without touching any hardware. It is the fastest way to debug a misaligned Arduino OLED bitmap or a scrambled ESP32 TFT image.
When integrating custom graphics into bare-metal firmware for STM32, nRF52, PIC, or AVR microcontrollers, you often receive display assets as raw binary blobs or C arrays from a graphic designer. This tool bridges that gap - drop the .bin file or paste the array and instantly see what the display will render, without setting up a full development environment. It also helps with reverse engineering: if you are inspecting an unknown firmware blob, you can try different dimensions and bit depths to identify recognizable shapes.
LVGL's online image converter produces C arrays for use in the LVGL embedded GUI framework. These are often 8 bpp or indexed-color formats. If you need to verify the output before integrating it into your LVGL project, paste the exported array here with the matching bpp setting to get an instant visual confirmation. This is particularly helpful when the LVGL image converter's preview does not match what you expect on-device.
E-ink displays from vendors like Waveshare, Good Display, and Pervasive Displays often use 1 bpp or 2 bpp framebuffers with specific byte-packing. Previewing those arrays is tricky because e-ink refresh is slow and you cannot step through frames on a debug monitor. This tool lets you preview each frame of an e-paper animation offline before flashing, dramatically speeding up the graphics iteration cycle.
When analyzing an unknown firmware binary - from an IoT device, a consumer product, or a legacy industrial controller - you sometimes encounter embedded image assets whose dimensions and bit depths are not documented. This tool's flexible width/height controls and bpp selector make it easy to systematically try different parameters until recognizable images emerge. Upload the suspected image region as a .bin file and explore.
Understanding how pixels map to bytes is a foundational skill in embedded programming. This tool makes that relationship tangible. Toggle the bit order and watch the image mirror itself. Change the bpp and see how the byte count per row changes. Adjust the width one pixel at a time and observe how the image shifts when the row stride is wrong. It is an interactive learning tool as much as a practical debugging utility.
The parser is designed to accept the widest possible range of inputs without manual cleanup. Here are all the formats it understands:
// width: 128, height: 64
static const uint8_t myImage[] PROGMEM = {
0x00, 0x00, 0xFF, 0x81, 0x81,
0xFF, 0x00, 0x00
};pub const LOGO: &[u8] = &[
0x00, 0xFF, 0x81, 0x81,
0x81, 0xFF, 0x00,
];00 FF 81 81 81 FF 00 00
00 18 24 42 81 FF 00 0000FF818181FF0000
00182442...Drag any .bin file onto the drop zone. The raw bytes are loaded directly - ideal for SPI captures, memory dump files, or flash read-backs from embedded tools like J-Link, OpenOCD, or esptool.
Arrays produced by LCD Image Converter, Bitmap2LCD, or dot2pic.com paste directly without any cleanup. The parser strips all surrounding code scaffolding automatically.
In a 1-bit-per-pixel framebuffer, each byte encodes 8 consecutive horizontal pixels. For a 128-pixel wide display, each row requires exactly 16 bytes (128 ÷ 8 = 16). A full 128×64 monochrome image therefore occupies 1,024 bytes. With MSB-first ordering, the most significant bit (bit 7) of the first byte in a row represents the leftmost pixel, and bit 0 represents the 8th pixel. With LSB-first, bit 0 is the leftmost pixel. Choosing the wrong bit order produces a horizontally scrambled image where each group of 8 pixels appears reversed.
When image width is not a multiple of the pixel-per-byte ratio, the last byte of each row contains padding bits. For example, a 100-pixel wide 1 bpp image requires 13 bytes per row (⌈100 ÷ 8⌉ = 13), with 4 unused bits at the end of each row. This tool handles that padding correctly by computing the ceiling of width divided by pixels-per-byte, then discarding excess bits during reconstruction.
Most embedded displays have a gamma response that differs from a standard PC monitor. The gamma slider (default 1.0, range 0.1–3.0) lets you simulate your display's tone response. Reducing gamma below 1.0 brightens the midtones, which is useful for simulating displays with native gamma lower than 2.2. Increasing it toward 3.0 darkens the midtones, simulating high-contrast displays like unlit e-ink.
| Display | Resolution | Bit Depth | Array Size | Bytes/Row |
|---|---|---|---|---|
| SSD1306 OLED | 128×64 | 1 bpp | 1,024 bytes | 16 |
| SSD1306 OLED (small) | 128×32 | 1 bpp | 512 bytes | 16 |
| SH1106 OLED | 132×64 | 1 bpp | 1,056 bytes | 17 |
| ST7735 TFT | 128×160 | 8 bpp | 20,480 bytes | 128 |
| ILI9341 TFT | 240×320 | 8 bpp | 76,800 bytes | 240 |
| GC9A01 Round | 240×240 | 8 bpp | 57,600 bytes | 240 |
| Waveshare e-ink 1.54" | 200×200 | 1 bpp | 5,000 bytes | 25 |
| Sharp Memory LCD | 400×240 | 1 bpp | 12,000 bytes | 50 |
This almost always means the width or height is wrong. The decoder reads a fixed number of bytes per row based on width and bpp, so if width is even slightly off, every row is shifted relative to the one above it, causing a diagonal stripe or total scrambling. Double-check that your width matches the display resolution exactly. The "Hint: Expected X bytes per row" indicator can help you cross-check against your array's row length.
A horizontally mirrored image (each group of 8 pixels appears flipped) is the classic symptom of wrong bit order. Toggle from MSB-first to LSB-first (or vice versa) and the image should correct itself. This happens because different display libraries pack pixels into bytes in opposite bit directions.
Switch the Row Order from "Top → Bottom" to "Bottom → Top." This is common with BMP-derived arrays because the BMP file format stores rows from the bottom of the image upward. Most embedded LCD drivers, however, scan top-down, so any array derived from a BMP file without explicit row reversal will appear flipped.
Yes, absolutely. image2cpp is the most popular image to C array converter for Arduino OLED projects. Paste its output directly into the Array Text box. If the output includes a // width: X, height: Y comment, the tool auto-fills the dimensions. Select 1 bpp and MSB-first to match the Adafruit GFX default.
No. All processing is done in your browser using the HTML5 Canvas API and the Web File API. No bytes, no arrays, and no images are transmitted to any server. This tool works fully offline once the page is cached, making it safe for use with proprietary firmware or NDA-protected display assets.
Bitmap2LCD and LCD Image Converter are desktop applications focused on converting images into arrays. This tool does the opposite: it takes an existing array and shows you what it looks like as an image. It is a browser-based, zero-installation reverse visualizer - you do not need to download or install anything. It complements those tools rather than replacing them.
The current version supports 1, 2, 4, and 8 bpp grayscale formats. RGB565 (16 bpp color) is on the roadmap. For now, if you have an RGB565 array, you can view the raw byte structure using the 8 bpp mode, which will show you the byte values but not the correct colors.
Discover more free developer tools that might interest you