STEGOSCAN: Look Inside an Image for What Should Not Be There
A picture file is a container, and a container has places a picture does not need: bytes after the end marker, chunk types nobody defined, comment fields, and the least significant bit of every pixel. This walks the container block by block, shows you what is in those places, and draws the bit plane so you can look at it yourself. It finds careless hiding. It does not find good hiding, and the notes say exactly where the line is.
Open the picture
PNG, JPEG, GIF, WebP or BMP. It is read in this tab. Nothing is uploaded, and the page works with the network off.
What stands out
What the file is made of
Anything after the end of the image
Text and comments carried in the container
Metadata
Printable runs in the raw bytes
The least significant bit of every pixel
A photograph's least significant bits are close to noise, so this normally looks like television static. Flat blocks, text, edges or a rectangle of different-looking noise in one corner are the things worth seeing.
What the chi-square does and does not mean. It measures how far apart the counts of each pair of neighbouring values, 0 and 1, 2 and 3, and so on, still are. Writing random data over every least significant bit pushes each pair towards equal, so a very small chi-square, meaning a tail probability near one, is the signature of that kind of hiding. A large chi-square is what an ordinary photograph looks like. Neither is proof: a heavily denoised picture, a small palette, a screenshot or a resave can produce either number honestly, and anything cleverer than replacing the low bits wholesale will not move it at all.
What this is, and what it is not
It reads the container, not a guess about it. PNG is walked chunk by chunk from the signature to IEND, each chunk's CRC recomputed and compared. JPEG is walked marker by marker, through the entropy-coded scan, to EOI. GIF is walked block by block to the trailer, WebP chunk by chunk through the RIFF payload, BMP by its two headers. Whatever is left over after the format's own end marker is the trailing data, and it is measured from that marker rather than from a guess.
Bytes after the end are the commonest hiding place there is. Every viewer stops at the end marker, so anything after it is invisible to a viewer and survives being emailed, posted and downloaded. The first 256 of those bytes are printed as a hexdump and the first few are matched against a table of magic numbers, which is how ZIP, RAR, gzip, 7-Zip, XZ, bzip2, tar, PDF, a second image, an executable and plain text announce themselves. A ZIP appended to a PNG is a real ZIP: rename the file and your unarchiver will open it.
What the bit plane is, and what to look for. The least significant bit of each channel is pulled out and drawn as black and white. In an ordinary photograph those bits are close to noise, so the plane looks like television static. What stands out is structure: a flat block, an edge, readable text, or a rectangle of different-looking noise in one corner where a tool wrote a payload and stopped. Judging that is your eyes' job, not the page's.
The chi-square is a hint with a known failure mode. It measures how far apart the counts of each neighbouring pair of values still are. Writing random bits over every least significant bit pushes each pair towards equal, so a very small chi-square is the signature of that. A large one is what a normal picture looks like. It is fooled in both directions: a denoised or heavily compressed picture can look balanced with nothing hidden, and a payload written into part of the frame, or into the JPEG coefficients, will not move it at all.
On a JPEG the pixel bit plane means something different. JPEG stores frequency coefficients, not pixels, so the pixels the bit plane is drawn from are the output of the decoder rather than anything a hider wrote. Hiding in a JPEG is done in the coefficients, by tools like F5 and outguess, and that does not show in a pixel bit plane at all. What is still worth reading on a JPEG is the segment list, the comments, the APP blocks and anything after EOI.
The strings list is ASCII only. Runs of six or more printable ASCII characters, deduplicated, with the offset where each first appears. Most of what it finds belongs to the format: chunk names, colour profile descriptions, encoder banners. Text stored as UTF-16, or in any other encoding, will not appear, and neither will anything compressed. The threshold is yours to change.
Metadata is reported where the format puts it. EXIF from a JPEG APP1, a PNG eXIf chunk or a WebP EXIF chunk, with the IFD walked and the GPS sub-IFD followed and turned into a decimal position. XMP from a JPEG APP1, a PNG iTXt keyed XML:com.adobe.xmp, a WebP XMP chunk or a GIF application extension. IPTC from the Photoshop resource block in APP13. ICC is reported as present or not, because the profile itself is a colour table rather than something about you.
This finds careless hiding, not good hiding. Everything here looks for data that was put somewhere obvious, or put somewhere subtle by a tool that did not cover its tracks. It cannot see a payload encrypted before it was embedded and spread thinly across the frame, a message in the JPEG coefficients, anything in the palette ordering, or anything in a format-specific corner nobody has written a check for. A clean result from this page means nobody was careless. It does not mean nothing is there.
Nothing is uploaded. The file is read into this tab with the browser's own file reader, parsed here, drawn here on a canvas, and dropped when you leave. Watch the network tab while you use it, or turn the network off first.
Questions people ask
Does the image get uploaded?
No. It is read in the browser, and every byte of the parsing, the hexdump and the bit-plane drawing happens in this tab. Turn the network off and the page works exactly the same.
It says there is a ZIP after the end. How do I open it?
Copy the file, rename the copy so it ends in .zip, and open it with your normal unarchiver. Most unarchivers will also open it under its original name; they scan backwards for the archive's own directory rather than trusting the extension.
What does a high chi-square mean?
That the pairs of pixel values are still far apart, which is what an untouched photograph looks like. The suspicious case is the opposite one: a very small chi-square, meaning the pairs have been flattened, which is what writing random data over every least significant bit does. Neither is proof on its own.
The bit plane looks like static. Is that bad?
No, that is the normal case. A photograph's low bits are close to random because the sensor noise is. What is worth a second look is structure in the plane: flat areas, an edge, text, or a patch where the texture of the noise changes.
Can it find a message hidden with a password?
It can sometimes see that something was written, from the bit plane or the statistics. It cannot read it, and it does not try. Recovering an encrypted payload needs the key and the tool that wrote it.
Why does it flag chunks as unknown?
Because a chunk type that is not in the format's specification is the easiest place to park data that every viewer will step over. Most unknown chunks are harmless, from a camera or an editor with its own extension, but they are worth naming rather than skipping.
Which formats does it read?
PNG, JPEG, GIF, WebP and BMP. TIFF, HEIC and AVIF are not read, because each is a substantial container format of its own and half-reading one would be worse than saying so.