Bit Plane Viewer

Exact or approximate, at a glance: PNG and BMP samples and GIF palette indices are read straight from the file, so the planes show the stored values; JPEG, WebP and AVIF are decoded by the browser first, so their values can differ slightly and a banner says so. That difference decides whether an LSB conclusion is safe, which is why it is stated before anything else.

An 8-bit colour channel stores each pixel as a number from 0 to 255, and that number is eight bits. A bit plane takes one of those eight positions — say bit 7, the most significant, or bit 0, the least significant — and draws it for every pixel as a black-and-white picture: white where the bit is 1, black where it is 0. A normal RGB image therefore has 24 planes (three channels times eight bits), an RGBA image has 32, and an 8-bit gray image has 8. This page shows all of them side by side in an overview grid, then lets you open any one at full resolution.

Start with the grid. Each cell is one plane, labelled such as R bit 0, with the share of set bits (density) and a Shannon entropy figure underneath. The cells are density thumbnails: when a large image is shrunk to fit, each thumbnail pixel is the average of the block of bits it covers, not a single sampled bit, so one stray line of noise cannot vanish in the downscale. Click a cell to open it in the single-plane viewer, where the picture is drawn pixel for pixel with nearest-neighbour scaling. Nothing is smoothed, because smoothing would destroy exactly the detail you came to look at.

Keyboard stepping follows the usual order for this kind of viewer: Left and Right move to the next or previous bit, Up and Down move to the next or previous channel. The pixel inspector under the image lists the binary value of every channel at the pixel you hover over, with the bit you are viewing highlighted, and a click pins it.

In an ordinary photograph the high planes carry the picture. Bit 7 of the red channel is, in effect, a thresholded copy of the red channel: large smooth regions of white and black that follow the shapes in the scene. Moving down, bit 6 and bit 5 still look like the image but with finer banding. By the time you reach bits 1 and 0 the plane usually looks like television static, because the lowest bits record sensor noise, rounding and compression residue rather than scene content.

The tool puts three numbers on that impression. Density is the share of pixels whose bit is 1. Entropy is the Shannon entropy of the bit distribution, from 0 (every bit the same) to 1 (exactly balanced). Transition rate is the share of horizontally adjacent pixel pairs whose bit differs: a smooth high plane changes rarely, so its transition rate is low, while a noise-like plane changes about half the time. The longest run of identical bits in raster order is shown too. A short reading line combines them into constant, structured, noise-like or mixed. Treat it as a hint: a noise-like low plane is normal for a photograph, so noise alone proves nothing, and a perfectly structured low plane does not prove nothing is hidden.

People who hide data in the least significant bit usually overwrite the low bit of successive pixels, starting at the top-left corner and moving along each row until the message runs out. That leaves a recognisable shape in the bit 0 plane: the upper part looks like random static while the lower part still looks like whatever the image would have looked like without the message. Where the static stops is roughly where the message ends.

The payload-extent strip is built for exactly this. It cuts the plane into up to 256 equal blocks in raster order, plots each block's entropy as a thin strip under the image, and marks a boundary only when the plane switches between low and high entropy and then stays there for at least three blocks. If it finds one it shows an approximate bit and byte count for the span. It will say No clear boundary when it finds none, and that wording is deliberate: a missing boundary is not evidence that the image is clean, because a payload spread across the whole plane, or a carrier whose low plane is already noisy, produces no visible edge.

Read the size estimate with its assumptions in mind. It counts one bit per pixel of the plane or composite on screen, in the pixel order you chose, so it is the length of the noisy span, not a recovered payload length. It does not include headers, encryption overhead or compression, and it does not undo multi-channel embedding: if a tool wrote its bits round-robin across red, green and blue, each single-channel plane shows only about a third of the payload. In a test with known payloads embedded in a flat low plane, the estimated span landed within about one block (192 bits on a 256 by 192 image) of the true length for payloads from about 100 bytes up, for both random bytes and plain text; spans shorter than three blocks are not flagged at all.

Other patterns worth recognising: a plane in which you can read a picture or text outright, which usually means someone deliberately put an image into one bit position; a regular grid or QR-like texture; or a plane that is completely flat when its neighbours are not. For anything that looks like a payload, the bit peek reads the next 64, 128 or 256 bits from a pixel you choose as bits, hex and ASCII, in either bit order. That is a preview to confirm that a plane holds something, not an extraction; the dedicated extractor tools linked below handle channel order, bit depth and traversal options.

JPEG does not store pixel values. It stores quantised frequency coefficients for 8-by-8 blocks and reconstructs pixels when the file is opened. The reconstruction rounds, and the rounding usually changes the low bits of many pixels, so the bit 0 plane of a JPEG is dominated by compression artefacts. A spatial LSB payload written into the pixels before saving as JPEG is therefore likely to be corrupted or destroyed, and the reconstructed LSB plane cannot reliably represent the original pixel values; how much survives depends on the quality setting, any other edits and the payload. The same applies to lossy WebP and to AVIF.

For that reason the viewer does not treat these formats like PNG. They are decoded by the browser and a banner states that pixel values may differ slightly from the file and that LSB conclusions should not be drawn from the view. JPEG gets an extra explanation. When you have a choice, work from the lossless original: PNG, BMP or GIF are read straight from the file's stored samples.

A browser decodes images for display, and display means applying colour management, possibly honouring an orientation tag, and compositing with alpha. Canvas-based decoders also commonly hold pixels with premultiplied alpha, where a semi-transparent pixel's red, green and blue are scaled by its alpha and then scaled back when read. The round trip is not always exact, so the colour of a semi-transparent pixel can change by a few units — which is enough to flip a low bit.

The exact path avoids every one of these. For PNG the tool parses the chunks itself, validates every CRC and reports the chunk that fails, inflates the image data, undoes the scanline filters and reads the samples directly. Gamma, colour-profile and transparency chunks are ignored on purpose, so a plane shows the number that is in the file. BMP rows are un-padded and flipped to top-down; GIF palette indices are read from the stored image data. The palette indices are exact, but frame compositing and disposal are the viewer's own approximation (see Limitations). The decoder also checks the decompressed size against the size the header implies, so a small file that claims to expand to gigabytes is refused rather than allocated.

The reconstruct slider is the classic bit-plane-slicing exercise. Keep only the top N planes of each channel and zero the rest, or mirror it by removing the lowest N planes, and the page shows the result beside the original with the largest per-pixel error that setting can cause. Keeping the top four planes of an 8-bit channel can be off by at most 15 on any pixel, because the four dropped planes hold values 8, 4, 2 and 1 and 8 + 4 + 2 + 1 = 15. Keeping only the top plane leaves two values per channel and the picture collapses to a posterised outline. A difference preview amplifies the gap so you can see where the dropped planes mattered.

This is also a quick test of where an image keeps its information. If dropping the lowest four planes barely changes the picture, the low planes carry little of the visible content, which is the normal case for a photograph and the reason low-bit data hiding is hard to see by eye.

This viewer is for looking and understanding. When the planes suggest something, move to a tool built for the next job: the LSB Extractor recovers payloads with explicit channel, bit and ordering settings; StegSolve and Zsteg run their full sets of extraction and combination tricks; the Steganography Detector applies statistical tests such as chi-square and RS analysis to give a measured suspicion level; the Hex Viewer shows the raw bytes of the file, including anything appended after the image data; and the EXIF Viewer reads the metadata. The Hex Viewer, LSB Extractor, StegSolve, Zsteg and Steganography Detector open with the file from this page already loaded; the EXIF Viewer opens empty, so load the file there. To practise on a file you know contains a message, embed one first with the LSB Embedder, the Color Channel Hider or the Image Steganography Hider, then open the result here and look at the extent strip.

One reasonable order for an investigation, not a mandatory one: look at the planes here to spot structure and a possible payload boundary; run the Steganography Detector for statistical evidence of LSB embedding; try the LSB Extractor with the channel, bit depth and traversal the planes suggest; and open the Hex Viewer to check the raw bytes and anything appended after the image data. Real challenges often need a different path.