Image-in-Image Hider

Every pixel of a picture is stored as three numbers, one each for red, green and blue, from 0 to 255. Changing the lowest bit of one of those numbers moves a colour by 1 out of 255, which is usually invisible. This tool treats the secret image as a long list of bytes (3 bytes per pixel: red, green, blue), and writes those bytes bit by bit into the lowest bits of the cover's colour values. The more bits per value you use, the bigger the secret can be, and the more the cover changes.

The data is written in a fixed layout with two layers. The outer frame is never encrypted: a 4-byte length, the secret's width and height (4 bytes each) and a 1-byte flag that says whether the secret is encrypted, which is 13 bytes in all. After it come the secret's colour bytes. With a password, those colour bytes are replaced by the encrypted form: a 4-byte ciphertext length, a 16-byte salt, a 12-byte IV and then the ciphertext with its 16-byte authentication tag, which is 48 bytes more than the plain colour bytes. So a password adds 48 bytes on top of the 13-byte frame, 61 in total. The Extractor reads the same layout back, so it can find the hidden image by trying each combination of bit depth and channels and checking whether a valid header comes out. The output is always a PNG, because PNG keeps every pixel value exactly.

Recommended (2 bits on red, green and blue) is the default and is a sensible start. Stealth changes the fewest bits, but it only uses the blue values, so the secret has to be small. Quality uses 4 bits on every channel and fits the largest secret, but the cover changes the most: noise can appear in smooth areas such as sky, so judge the before-and-after view.

Forensic mode adds a Custom setting (bit depth 1 to 4 and the channels Blue, Red + Blue, or Red + Green + Blue). You only need it to match a file that was made with settings other than the three presets; the Extractor's Auto-Detect tries every combination, so you do not have to remember them.

The cover holds floor(width × height × channels × bits ÷ 8) bytes. The hidden data needs 13 bytes of frame plus 3 bytes for every pixel of the secret, and a password adds 48 bytes. So the largest secret has floor((capacity − 13) ÷ 3) pixels, or floor((capacity − 61) ÷ 3) with a password, always a whole number of pixels. If your secret has more pixels than that, the tool shrinks it, keeping its shape (each side is rounded down), with nearest-neighbour scaling (it picks the closest original pixel, so fine detail is lost). It never cuts the data off, and it never enlarges a small secret.

The table below shows the largest square secret for common cover sizes, from the same functions the encoder uses. A password changes these figures by only a few pixels. A secret that is not square keeps its shape and fits fewer pixels on its long side.

It depends on the mode and on how full the cover is. We measured PSNR (a standard distortion figure; higher means closer to the original) on seven 800 × 600 crops of two real landscape photographs and averaged them. Two photographs are a small sample, so treat the numbers as a guide, and trust the figure the tool shows for your own files. With the secret filling the cover, Stealth gave 56.0 dB, Recommended 44.1 dB and Quality 31.9 dB. A smaller secret changes fewer pixels and scores higher (see the table). PSNR is computed over the red, green and blue values of the cover before and after hiding (alpha is ignored; a transparent cover is flattened first). The SSIM shown is a simplified whole-image version, not the usual windowed SSIM, so use it only to compare runs of this tool; it was 0.9848 or better in every case we measured.

A high PSNR means the numbers moved little, which usually means a viewer cannot see the difference; it is not a guarantee, and it says nothing about whether a program can detect the change.

A browser's canvas cannot keep exact colour values under transparent or semi-transparent pixels, so bits hidden there would be lost. If a cover has any transparent pixel, the Hider fills the transparent areas with white and says so, and the result is an opaque PNG. The secret image is stored as red, green and blue only, so its transparency is not kept either: in Chromium, a fully transparent secret pixel comes back black, and a partly transparent one comes back opaque with its colour (rounding can shift it slightly). Other browsers may handle transparent pixels differently.

If you set a password, the payload is encrypted before it is hidden, in your browser, with the Web Crypto API. The cipher is AES-256 in GCM mode. The 256-bit key is derived from your password with PBKDF2 using HMAC-SHA-256 and 100,000 iterations. Every encryption generates a fresh random 16-byte salt and a fresh random 12-byte IV with the browser's cryptographically secure random generator (crypto.getRandomValues), so encrypting the same message twice gives different bytes. The stored layout is a 4-byte length, the salt, the IV, then the ciphertext followed by a 16-byte authentication tag — 48 bytes added in total. The tag means a wrong password, or any change to the ciphertext, makes decryption fail instead of returning garbage.

These are standard, widely used primitives, but this implementation has not had an independent audit, and using them does not make the system unbreakable. Their limits matter. Anyone who finds the hidden data can copy the ciphertext and try passwords against it offline, so your password is the real defence: use a long random passphrase, not a word or a date. The key derivation uses 100,000 PBKDF2-HMAC-SHA-256 iterations. This is below OWASP's commonly cited 600,000-iteration recommendation for password storage. That recommendation is not a direct requirement for this file-encryption format, but the lower count makes a strong, unique password especially important. The iteration count is fixed in the code and is not written into the file, so raising it requires a new, versioned format so that files already made can still be opened.

Encryption hides what the data says, not that it exists, and it does not hide the length: AES-GCM ciphertext is the same length as the plaintext, and the encrypted layout adds a fixed 48 bytes of overhead: its own 4-byte length field, the salt, the IV and the authentication tag, separate from any length or framing the tool puts around it. No padding is added. There is no key file and no way to recover a forgotten password. We have not measured key-derivation time on phones or older devices, so very large batches or slow devices may take noticeably longer per file. The tool is intended for educational and personal use; do not rely on it as the only protection for sensitive information, or against a well-resourced adversary.

The password encrypts the secret's pixels. The 13-byte header in front of them is not encrypted, so anyone who runs the Extractor's Auto-Detect on the file can see that a hidden image of a certain width and height is present and that it is encrypted. Without the right password they cannot read it, and a wrong password gives a clear "Wrong password" error, not noise.

A hidden picture is structured data, so it can be visible in the low bit planes of the stego PNG, and statistical tools for LSB steganography can flag the change. The Extractor's LSB-balance numbers are a weak hint only: in our test a clean test image measured 0.476 / 0.501 / 0.500 and the same image with a hidden picture 0.509 / 0.467 / 0.507, so they cannot tell the two apart. A payload found by Auto-Detect indicates a hidden image in this tool's format; it is a match on the header, not proof of anything else.