How digital images store pixels in binary — resolution, color depth, and raw pixel data
At the most fundamental level, a pixel is just a bundle of binary numbers. When I first started learning about digital images, I assumed pixels were these mysterious little colored squares that just magically appeared on screen. The truth is far more interesting: every pixel is stored as a sequence of bits that directly encodes color information. A typical pixel takes 24 bits — 8 for Red, 8 for Green, and 8 for Blue.
Take a pure red pixel in a standard image. Its binary representation is 11111111 00000000 00000000. The first 8 bits are all 1s, meaning maximum red intensity (255 in decimal). The next 8 bits are all 0s — no green. Same for the last 8 bits — no blue. The computer reads those 24 bits, interprets them through the display driver, and lights up exactly one tiny phosphor on your screen. Multiply that by millions of pixels, thirty times per second, and you get motion video.
Key Insight: A 1920×1080 image contains 2,073,600 pixels. At 24 bits each, that is 49,766,400 bits — roughly 6.2 MB of raw binary data before any compression.
Resolution tells the computer exactly how many pixels exist in both directions. A 640×480 image has 640 columns and 480 rows of pixels — 307,200 total. Every one of those pixels occupies a specific position in the pixel array, and the computer reads them in scanline order: left to right, top to bottom. This is the same fundamental principle that CRT televisions used, but instead of an electron beam, the computer is reading binary data.
I find it helpful to think of an image as a giant spreadsheet where each cell holds a binary color value. Cell (0,0) is the top-left pixel, cell (1,0) is the next one to the right, and so on. When you zoom into an image and see the pixelation, you are literally seeing the grid structure that the binary data describes. The higher the resolution, the more binary data is needed, and the more detail the image can hold.
The term "color depth" refers to the number of bits used to represent a single pixel. A 1-bit image uses exactly 1 bit per pixel: 0 means black, 1 means white. That gives you a total of just 2 colors. An 8-bit grayscale image uses 8 bits per pixel, giving 256 shades of gray. A 24-bit true color image uses 24 bits per pixel, which equates to 16,777,216 possible colors — enough for photorealistic images.
Every additional bit doubles the number of representable colors. Going from 8-bit (256 colors) to 16-bit High Color (65,536 colors) doubles the color precision eight times over. This is why old video games look blocky and posterized — the hardware could only afford 8 or 16 bits per pixel, severely limiting the color palette. Modern displays use 30-bit or even 48-bit deep color for HDR content, where each color channel gets 10 or 16 bits instead of the standard 8.
A raw bitmap is the most straightforward way to store an image in binary. There is no compression, no metadata complexity — just pixel data in a linear sequence. If I have a 4×4 image with 24-bit color, the raw binary data is exactly 48 bytes: 4 pixels wide × 4 pixels tall × 3 bytes per pixel. The file starts with pixel (0,0) and ends with pixel (3,3).
Here is what a tiny 2×2 image with a red top-left, green top-right, blue bottom-left, and white bottom-right looks like in raw binary:
11111111 00000000 0000000000000000 11111111 0000000000000000 00000000 1111111111111111 11111111 11111111One detail that tripped me up early on is scanline padding. In many binary image formats like BMP, each row of pixels must start at a memory address that is a multiple of 4 bytes. If the pixel data for a row does not fill that requirement, extra padding bytes (zeros) are added at the end of each row. This means the binary structure of an image is not always a perfect contiguous block of pixel data.
For example, a 3×3 image with 24-bit color has 9 bytes per row (3 pixels × 3 bytes). Since 9 is not a multiple of 4, 3 padding bytes are added, making each row take 12 bytes in the file. The padding bytes are simply ignored when the image is displayed. This alignment requirement comes from old CPU architecture constraints where aligned memory access was significantly faster.
Raw pixel arrays are rarely used in practice because they produce enormous file sizes. A single 12-megapixel photo taken on a modern smartphone would be 36 MB as raw RGB data. That is why image file formats exist — they add headers, metadata, and compression algorithms on top of the basic pixel array.
Each format handles the underlying binary pixel data differently. PNG uses DEFLATE compression with a filter per scanline to predict pixel values and reduce entropy. JPEG divides the image into 8×8 blocks and applies a Discrete Cosine Transform (DCT), discarding high-frequency information that the human eye cannot easily perceive. BMP often stores pixels as-is with minimal header overhead. But underneath every format, the same fundamental structure exists: a grid of pixels where each pixel is a binary number representing color.
Let me walk through a practical calculation I use whenever I need to estimate image memory requirements. A 1080p image (1920×1080) at 24-bit color: 2,073,600 pixels × 3 bytes = 6,220,800 bytes, or about 5.93 MB. At 30 FPS video, that is 178 MB per second of uncompressed video. This is why hardware video encoding is essential — without compression, a 2-hour movie would need over a terabyte of storage.
Reducing color depth is one way to save space. A 16-bit High Color image (5-6-5 RGB, where Red gets 5 bits, Green gets 6, and Blue gets 5) uses only 2 bytes per pixel instead of 3. That same 1920×1080 image drops to about 4 MB. The trade-off is visible banding in smooth gradients like skies or skin tones, because there are fewer discrete levels to represent subtle color transitions.
Open the Binary Code Decoder in a new tab and enter some binary patterns to see the results instantly. All conversions happen in your browser — no data is sent to any server.