Text-in-Image Hider

Every pixel is stored as three numbers (red, green and blue) from 0 to 255. Changing the lowest bit of one of them moves a colour by 1 out of 255, which is usually hard to see. This tool turns your message into bits and writes them into those lowest bits. In front of the message it writes a 4-byte length, so the Extractor knows how many bytes to read. There is no signature, so the Extractor finds the message by trying settings, checking that the length fits the image, and looking at how the bytes read. A length that fits is not proof that a message exists; unrelated data could in principle pass the length check, which is why the bytes are also judged as text, encrypted data or noise.

The output is always a PNG, because PNG keeps every pixel value exactly. A JPEG you upload is read as pixels and written back as a PNG; saving the result as a JPEG again would destroy the hidden bits.

Quick mode uses Adaptive Edge on all three channels at 1 bit with no error correction. Standard mode lets you choose between Adaptive, Sequential and Scatter. Forensic mode adds the channel, the bit depth (1 to 3), Reed-Solomon and the Scatter seed, plus a separate "Plausible Deniability: Decoy + Real Payload" option: a plain-text decoy message goes in the lowest bit of the red channel and your real message, encrypted with a password, in the blue channel, with no signature in either; without the password only the decoy can be read. It is not undetectable: statistical tools can still flag the changes.

Sequential is the simplest layout. Scatter spreads the same changes over the whole image in an order that depends on a seed. Adaptive writes 2 bits at edge pixels, where small changes are harder to see, and 1 bit elsewhere. Which of these is hardest to detect, or least visible, is not something we have shown: in our measurements Adaptive had a slightly lower PSNR than Sequential at the same fill. Look at the before-and-after view and the figures for your own image.

Every capacity figure on this page is the longest message you can type, in bytes of plain text, after the other overhead is taken off. Raw capacity is floor(width × height × channels × bits ÷ 8) bytes. The image stores its own 4-byte length header first, so the room for what is stored is that minus 4. Adaptive is counted at 1 bit per value, the guaranteed minimum; its real capacity is higher because edge pixels carry 2 bits (about 16% higher on average over our seven photo crops). A password then takes 48 more bytes: the encrypted layout is its own 4-byte length field, a 16-byte salt, a 12-byte IV and a 16-byte authentication tag around the ciphertext, which is a separate field from the image's header. For 200 × 150 at 1 bit on all channels that is 11,250 − 4 = 11,246 bytes for a plain message and 11,246 − 48 = 11,198 with a password. Reed-Solomon takes a 16-byte header plus 10, 20 or 30 parity bytes per 223 bytes. The capacity bar and the Hide button use these same numbers, so a message that fits the bar is written in full. The Extractor reads at most 5,000,000 stored bytes (the message plus password and parity overhead), and the Hider applies the same limit to the stored bytes, so with a password the longest message at that limit is 48 bytes shorter.

The table below uses exact byte counts (1 KB = 1,024 bytes would give about 759 KB for 1920 × 1080 at 1 bit). The figures are for the largest message, after the length header, with and without a password.

It depends on how full the image 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. With the image full, Sequential on all channels at 1 bit scored 51.1 dB and Adaptive 50.1 dB; at 5% full they scored 64.1 dB and 62.8 dB. Two photographs are a small sample, so treat the numbers as a guide. A high PSNR means the numbers moved little. It does not guarantee that nobody can see a difference, and it says nothing about whether a program can detect the change.

After encoding, the tool shows the PSNR and SSIM measured on your own file next to the original, computed over the red, green and blue values. The SSIM is calculated on 8 × 8 blocks of luminance.

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 seed sets the order in which pixels are visited. It is a 32-bit number fed to a simple linear congruential generator, so there are only 2^32 (about four billion) possible seed values and a program can try them all. The seed is not encryption and not a second password: the password is what protects the text. Without the right seed the Extractor reads the wrong pixels, which is a nuisance for someone who does not know it, not a defence.

The number shown is a p-value from a classic chi-square test on pairs of pixel values (2k and 2k+1), calculated per channel from the counts of each pair. Replacing lowest bits with random-looking bits makes the two counts in each pair nearly equal, and then the p-value is close to 1; in the images we tested, unequal pair counts gave low p-values, but this varies with the image. So here a high p-value means that the pair counts look equalised, which is what full replacement by random-looking bits produces. It reacts when the hidden bits look random and fill most of the image. Plain text is not random, and in our test the p-value stayed at 0.000 for a text payload at every fill level, so a low p-value does not mean an image is safe. For random-looking data, such as an encrypted message, at 100% fill the p-value was between 0.861 and 1.000 for Sequential and between 0.946 and 1.000 for Scatter across all channels of the seven photos. Adaptive reached 1.000 on some but stayed at 0.000 on at least one, so it did not reliably trigger the test.

At 60% fill Sequential stayed at or below 0.002 and Adaptive at 0.000, while Scatter reached 0.964 on one photo. That is one test on seven crops of two photographs, so it says nothing general about detection performance. Do not read it as a ranking of how hard each method is to detect by other tools. Treat the number as one diagnostic signal.

Transparent and semi-transparent pixels can have their colour values altered when a browser reads or saves an image (canvas processing premultiplies colour by alpha), which loses hidden bits placed there. If a cover has any transparent pixel, the Hider fills the transparent areas with white, says so, and saves an opaque PNG. Check the extracted result before relying on it; an opaque image is the safer choice.