LSB Embedder

A decoded image is a grid of pixels, and each pixel is four numbers from 0 to 255: red, green, blue and alpha. Least-significant-bit (LSB) steganography overwrites the lowest bit (or the lowest 2, 3 or 4 bits) of some of those numbers with the bits of your message. At 1 bit a colour value moves by at most 1 out of 255. The tool decodes your image in a Web Worker, changes values in memory, and saves the result as a PNG. PNG is lossless, so every changed value stays exactly as written until something re-encodes the picture.

Nothing here is encryption: without a password the message is stored as plain bytes, and the Extractor (or any tool that knows the layout) reads it back. With a password the payload is encrypted first, but the 20-byte LSBSTEG header that precedes it is not, so the image still shows that a payload of a given size exists.

Hide the letter A (byte 65, bits 01000001) with Sequential, 1-bit, R + G + B, into three pixels whose colours are (200, 100, 50), (201, 101, 51) and (202, 102, 52). The eight bits go into the lowest bit of eight consecutive values: R, G, B of pixel 1, R, G, B of pixel 2, then R, G of pixel 3. Result: pixel 1 becomes (200, 101, 50), pixel 2 becomes (200, 100, 50) and pixel 3 becomes (202, 103, 52). Five of the 8 values changed (100→101, 201→200, 101→100, 51→50, 102→103), each by exactly 1; the other three already held the right bit, and the Blue value of pixel 3 was not touched. Reading the lowest bit of those eight values in order gives 0, 1, 0, 0, 0, 0, 0, 1 — the byte 65 again. (The real tool starts at pixel 55 and writes the header first; this example starts at pixel 1 to keep the numbers short.)

Quick mode always uses Sequential, 1 bit, on R, G and B. Standard adds PRNG order, a Blue-only variant, 2-bit depth and channel selection. Forensic adds 3 and 4 bits, the Alpha channel and deflate compression.

Sequential writes the payload into pixels 54, 55, 56 … in raster order (pixels 0–53 hold the header). PRNG picks pixel positions with a partial Fisher–Yates shuffle driven by Mulberry32, a small non-cryptographic generator, seeded with the first 4 bytes of SHA-256 of your password. That is a 32-bit seed (about 4.3 billion values), so it spreads the changes but is not a secret: the AES encryption is what protects the content. With no password the seed is 0.

Each extra bit of depth doubles the capacity and the largest possible change to a colour value (1-bit ±1, 2-bit ±3, 3-bit ±7, 4-bit ±15). The channel notes in the interface show each channel's share of perceived brightness using the standard BT.601 weights (R 30%, G 59%, B 11%); they are a guide to which changes the eye notices most, not a measure of detectability.

Capacity is (width × height − 54 header pixels) × channels × bit depth ÷ 8, rounded down to whole bytes. The 20-byte header sits in its own 54 pixels, so it is not taken off again. A password costs 48 bytes (4-byte length + 16-byte salt + 12-byte IV + 16-byte authentication tag). The capacity bar and the encoder use the same function, and the encoder refuses a payload that does not fit with a 'Payload too large' message instead of writing part of it.

Deflate (Forensic) is applied before encryption. The capacity bar counts the uncompressed size; the encoder checks the compressed size, which for short or already-compressed data can be slightly larger than the original. The payload's file name is not stored: when you hide a file, the Extractor guesses its type from its first bytes.

First a 20-byte header in pixels 0–53, always 1 bit per channel on R, G, B in order: the magic 'LSTG', a version byte, the variant, a channel bitmask, the bit depth, an encryption flag, a reserved byte, a compression flag, a reserved byte, the stored payload length (4 bytes, little endian) and a CRC-32 of the first 16 bytes. Then the stored payload — your bytes, deflated if you chose that, then AES-wrapped if you set a password — bit by bit, most significant bit first, using the chosen depth and channels. Pixels beyond the payload are not touched.

The Extractor reads the header first and uses the recorded settings when its CRC matches and the stored length fits the image. Images made by other tools have no such header, which is why the Extractor also has a ranked scan.

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 covers are accepted, up to 50 MB (10 MB on phones). A JPEG or lossy-WebP cover is fine: it is decoded to pixels first, and the output is a PNG — only converting the result back to JPEG destroys the data. TIFF opens only in browsers that can decode it. Animated GIF is not supported.

A browser canvas cannot keep exact colour values under transparent or partly transparent pixels, so a cover with transparency is placed on a white background before embedding (the tool tells you when it did). The Alpha channel option (Forensic) changes pixel transparency itself; browsers may then alter the colours of the pixels it touched. After encoding, the result screen re-reads the PNG in your browser and warns if any embedded byte changed. In our check, Chromium and WebKit kept every byte of a test image with alpha 254 on half its pixels, while Firefox altered 307 of 2,048 such pixels — so avoid Alpha unless you verify the output.

Overwriting low bits leaves statistical traces that tests such as chi-square, RS analysis and sample pairs can find, especially when most of the image is used. In our tests with this site's chi-square statistic (the Steganography Analyzer's whole-image test) on 8 crops of one photograph, a random payload filling 5%, 25% and 60% of the capacity gave a p-value of 0.000 (PRNG with a password reached at most 0.04 at 60%, over 4 runs of the 8 crops) — the same as the unmodified photographs — and a full image gave 0.85–1.00 for Sequential and 0.25–1.00 for PRNG (4 runs × 8 crops; the lowest value seen in each run was 0.25, 0.51, 0.64 and 0.85). The PRNG figures vary from run to run because the password-encrypted payload uses a random salt and IV, so the bits written differ each time; Sequential without a password is repeatable. That is one statistic on one photograph: it does not show that partly filled images escape other tests (such as the progressive chi-square test or RS analysis), and a text payload is less random than the random bytes used here.

Using less of the capacity and a textured photograph helps; PRNG order avoids filling the top rows completely. None of this guarantees that a detector will miss the data. The tool reports measured figures (PSNR, share of pixels changed) rather than a 'stealth score', because no single score can be tied to a measurement.