Image Steganography Hider

A decoded image is a grid of pixels, and each pixel is three numbers (red, green, blue) from 0 to 255. Least-significant-bit (LSB) steganography overwrites the lowest bit of some of those numbers with your message, so a colour value moves by at most 1 out of 255 at one bit per channel. This tool also offers two methods that work on frequency or noise patterns instead (DCT and Spread Spectrum), which behave very differently, as the tables below show.

Your image is decoded in the browser, changed in memory, and saved as a PNG. PNG is lossless, so every changed value stays exactly as written until someone converts the file to a lossy format such as JPEG. The Extractor on this site reads what this Hider writes; other tools use other layouts.

Use Adaptive LSB (the default) or Basic LSB when the PNG will travel as a file: email attachment, USB, a download link, a CTF challenge. They hold the most data and were read back byte for byte in every test. They are also the methods steganalysis tools check first, and neither survives a JPEG conversion: in our tests LSB data was lost at every JPEG quality from 100 down to 75.

Use Custom LSB when the payload is large, or when you need an exact bit depth. A 4-bit change can move a colour value by up to 15 out of 255, and on a smooth carrier the whole-image PSNR falls to about 32 dB when the image is full (see the measured table), which is visible in flat areas.

Use Spread Spectrum (Forensic mode) only for short messages that have to survive a JPEG conversion. It was recovered after JPEG quality 100, 90, 75 and 60 in our tests, but it holds at most about 1.2 KB and it adds visible noise: about 41 dB PSNR for a 29-byte message and about 25 dB when full. DCT is available but experimental: it was recovered only at JPEG quality 100 and lost at 90 and below, so it is not a safe choice for photos that will be re-compressed.

Capacity depends on the image's pixel dimensions and the algorithm, not its file size. Basic LSB holds width × height × 3 ÷ 8 bytes, minus a 4-byte length header. The tool then subtracts what it adds to your payload: a 1-byte filename frame (more when you hide a named file), 48 bytes if you set a password (the encryption wrapper's own 4-byte length, 16-byte salt, 12-byte IV and 16-byte authentication tag; this is separate from the image's 4-byte length header), and for Reed-Solomon a 16-byte header plus 10, 20 or 30 parity bytes per 223-byte block.

The capacity bar and the Encode button use the same function as the encoder, and the encoder itself refuses an oversize payload with a "Payload too large" message instead of writing part of it. This is tested at the exact limit and one byte over for every algorithm, with and without a password and Reed-Solomon (npm run test:unit:image). Adaptive LSB's bar shows the Basic LSB figure as a safe floor; an image with strong edges can hold more.

Every LSB method writes a 4-byte big-endian length, then your payload bits, most significant bit first, into the red, green and blue values in file order (or in a shuffled order when you set a seed). Alpha is never changed. There is no signature or marker, which is why the Extractor has to be told, or has to guess, the bit depth and channels.

DCT and Spread Spectrum work differently; each algorithm is described once, step by step, in the expandable "How Each Algorithm Works" list above, including how DCT forces coefficient signs and how Spread Spectrum adds and correlates a pseudo-random pattern.

The seed (Forensic mode) is a number from 0 to 999,999,999 that changes the order in which pixels (LSB methods) or noise values (Spread Spectrum) are used, so the same seed is needed to read the data. It is not a secret and does not encrypt anything: a billion values can be tried by a program. DCT ignores the seed. The password is what protects the content.

Reed-Solomon (Forensic mode, RS-10, RS-20, RS-30) is a real Reed-Solomon code over GF(2^8): 10, 20 or 30 parity bytes per 223-byte block repair up to 5, 10 or 15 changed bytes in that block. It repairs a few scattered edits. It does not rescue an image that was converted to JPEG, which changes most pixels, and damage beyond the limit is reported rather than silently accepted, although a very small chance remains that heavy damage decodes to wrong data, so pair it with a password when certainty matters.

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.

PNG, BMP, WebP and JPEG carriers are accepted, up to 50 MB (10 MB on phones). TIFF is listed by the file picker but only opens in browsers that can decode it: in our check a TIFF decoded in Safari (WebKit) and failed in Chromium and Firefox. Animated GIF is not accepted. The output is always a PNG, even when the carrier was a JPEG; hiding data in a JPEG carrier therefore gives a PNG (usually much larger than the JPEG) that still loses its data if converted back to JPEG.

The PNG is written through the browser's canvas. Browsers may not keep the colour values of fully transparent pixels exactly, so data written into transparent areas could be damaged. We have not measured this; use an opaque image to be safe. Alpha itself is never used to carry data.

Changing the lowest bits leaves statistical traces that tests such as chi-square, RS analysis and sample pairs can detect, especially when the image is nearly full. Writing only a little (the result screen shows the share of capacity used) and using a smooth-to-textured natural photograph both help against a simple test; neither guarantees that a detection tool will miss it. We have not run this tool's output against published steganalysis benchmarks, so the pages do not claim a detection rate. The Steganography Detector on this site runs four of those tests on any image so you can check the result yourself.