BMP Steganography Hider

A BMP stores an image almost raw: a 14-byte file header, a DIB header, an optional colour table (the palette) and then the pixel bytes, row after row. There is no compression and no lossy step, so every byte you write stays exactly as written until someone re-saves the file. That is why BMP is a convenient carrier for least-significant-bit (LSB) steganography: changing the lowest bit of a colour byte moves that colour value by at most 1 out of 255.

This tool offers three places to put data. Pixel LSB rewrites the lowest bits of the colour bytes. Palette LSB rewrites the lowest bits of the colour table instead and leaves every pixel alone. Reserved Bytes uses four unused bytes in the file header. The output is always a .bmp file, and only this tool's Extractor reads the format it writes.

Use Pixel LSB for 24 or 32-bit BMPs. It holds by far the most data. On an 8-bit BMP it works differently: each pixel is one palette index, so flipping low bits of an index points the pixel at a different palette entry, and that can change the colour a lot if neighbouring entries are not similar. For 8-bit files, Palette LSB is usually the gentler choice if the message is short.

Use Palette LSB when the BMP has a colour table of at least 16 entries (an 8-bit BMP, typically 256). It cannot hold much (see the capacity table below). Use Reserved Bytes only for three-byte hints; it is visible in any hex editor.

Capacity depends on the image's dimensions and your settings, not on the file size in megabytes. For Pixel LSB the raw capacity is the number of pixels × the number of channels used × the bit depth ÷ 8, rounded down: an 800 × 600 24-bit image at 1 bit on R, G and B is 800 × 600 × 3 × 1 ÷ 8 = 180,000 bytes. The tool then subtracts what it has to add. The stream that is written is a 4-byte length, a header (13 bytes for Pixel LSB, 7 for Palette LSB, 9 and 3 in the headerless plausible-deniability mode), and your payload. A password adds 48 bytes, and a Reed-Solomon level (RS-10, RS-20 or RS-30) adds a 16-byte header plus 10, 20 or 30 parity bytes per 223-byte block. Reserved Bytes is a separate layout with none of this (see the section on the two layouts).

The capacity bar and the Encode button use the same function the encoder enforces, so a payload that fits the bar is a payload that is written in full. The check is covered by a boundary test for every combination of method, bit depth, password and deniability setting. Sizes on this page are in bytes. Some capacity displays in the tool divide by 1,024 and label the result KB.

Pixel LSB and Palette LSB share one layout: a 4-byte little-endian length, then a header that starts with the signature STGB (53 54 47 42), then your payload. The header records the method, the bit depth, whether the payload is encrypted and, for Pixel LSB, which channels, which pixel order and which seed were used.

Reserved Bytes does not follow that layout at all. It has no 4-byte length, no STGB signature, no header, no encryption and no Reed-Solomon, so it can be read by anyone who knows where to look. The BMP file header has four reserved bytes at positions 6 to 9: byte 6 holds the length (1 to 3) and bytes 7, 8 and 9 hold the data, which is why the limit is 3 bytes. Because it has no signature, the Extractor cannot tell a Reserved Bytes message from a BMP whose reserved bytes were set for another reason.

BMP pixel data is physically stored in B, G, R (and A) byte order, one pixel after another, row by row, and a bottom-up BMP stores its bottom row first. This tool visits pixels in the order you chose (see below). Inside each pixel it takes the bits from the channels you selected in a fixed order, R then G then B then Alpha, so the Hider and the Extractor agree however you ticked the boxes. Bits are written lowest-first: the payload's first bit goes into the lowest bit of the first byte it uses.

Palette LSB is different: it walks the colour table entry by entry and uses each entry's stored bytes in file order, blue, then green, then red (the fourth byte of each entry is left alone). The 8-bit "Pixel LSB" variant has no channels at all: it changes the low bits of each pixel's single palette-index byte.

Bit depth is how many low bits of each colour byte are overwritten: 1, 2, 3, 4, 6 or 8 for Pixel LSB and 1 to 4 for Palette LSB. Each extra bit doubles the capacity and raises the maximum change per colour value (1 bit: up to 1 out of 255, 2 bits: up to 3, 4 bits: up to 15, 8 bits: the whole byte). Channels (Standard and Forensic mode) choose which of R, G, B and, on 32-bit files, Alpha receive bits. Pixel order is Sequential, which fills the image from the first pixel in file order, or Random (seeded), which visits pixels in a shuffled order driven by a seed number.

Important for extraction: the Extractor cannot discover these settings from the file. Its Auto-Detect tries R+G+B in sequential order at 1, 2, 3 and 4 bits for Pixel LSB. Data hidden at 6 or 8 bits, on a different channel selection, or in random order needs the exact same bit depth, channels, pixel order and seed entered in the Extractor's Forensic mode. The seed is stored in the file's header, but the header can only be read once the bits are found, so it cannot be recovered from the file. Write the seed down. The "Smallest change" quick preset uses 1 bit with a random seed, so it always needs this.

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.

Forensic mode offers three Reed-Solomon levels. The payload is split into blocks of up to 223 bytes and each block gets 10, 20 or 30 parity bytes, which lets the Extractor repair up to 5, 10 or 15 changed bytes per block, wherever they are. This is a real Reed-Solomon code over GF(2^8). The cost is 16 bytes of header plus the parity: for example a 1,000-byte payload grows by 16 + 5 × 10 = 66 bytes at RS-10.

Know its limits. It repairs a few scattered changed bytes, for example after someone edits a handful of pixels. It does not rescue a BMP that was re-encoded (JPEG changes almost every pixel), and damage beyond the limit in a block is reported as uncorrectable. Damage beyond the limit is usually reported as uncorrectable (in our test with 9 changed bytes against a limit of 5, at least 97% of trials were), but it can occasionally look like a different valid block and yield wrong bytes; a password protects against that, because the AES tag then fails. The 16-byte header is stored with the length twice but is not itself error-corrected.

Forensic mode has two separate features with similar names. The "Plausible deniability" switch only leaves out the 4-byte STGB signature from the header, so the Extractor's Auto-Detect cannot find the payload; you must use the Extractor's headerless option with the exact method and settings. It does not hide the change from statistical tests, and it should be used with a password.

"Plausible Deniability: Decoy + Real Payload" is a different, self-contained mode: a decoy message goes in the red channel's lowest bits with no password, and your real payload goes in the green channel's lowest bits, encrypted with AES-256-GCM. Anyone who opens the file without the passphrase can read the decoy only; with the passphrase, the Extractor also shows the real payload. It needs a 24 or 32-bit uncompressed BMP and rejects 8-bit files. Both layers are plain 1-bit substitution, so neither damages the other, and neither is hidden from steganalysis.

After encoding, the result screen can generate one watermarked copy of your original BMP per recipient. Each copy gets a unique ID derived from a random master secret, the recipient and a hash of the document, written with 1-bit Pixel LSB on R, G, B in sequential order (the Extractor's Auto-Detect finds it). You download a ZIP of the copies and, separately, watermark_keys.json. Keep that file: it is the only link between an ID and a recipient. The Extractor's Watermark Attribution panel compares an extracted ID with it. This identifies the copy; it does not stop the BMP being re-saved, which removes the ID.