JPEG Steganography Hider

F5 and JSteg hide bits in the quantized DCT coefficients of the JPEG: the numbers a JPEG stores for each 8×8 block instead of pixels. The tool parses the file, changes some coefficients, and writes the JPEG again without decoding it to pixels, so the picture is not re-compressed. JPEG Comment and APP Extension are not steganography at all: they put the data in a marker segment of the file, where a metadata viewer or hex editor shows it.

To hide data in a photo's pixels, or in a PNG, use the LSB Embedder or Image Steganography Hider. For steghide-compatible files use the Steghide Hider.

JSteg writes your bytes, after a 32-bit length, into the lowest bit of the magnitude of every luminance AC coefficient whose value is not 0, 1 or -1, in file order. Capacity is the number of those coefficients minus 32, divided by 8. The pairs-of-values chi-square test (Westfeld and Pfitzmann) can detect it, because writing random bits makes the counts of coefficient values 2k and 2k+1 equal; in our tests the test flagged JSteg files and not clean photos or F5 files (counts and conditions in the table How the Chi-Square Observation Was Made; 6 of the 60 clean photos were too small to test).

F5 uses matrix encoding: k bits of the message are carried by a group of 2^k − 1 usable coefficients, and a group needs at most one change to carry them, so a larger k means fewer changes per bit. The tool picks the largest k that fits. F5 only ever moves a coefficient's magnitude down by one, never up, so some coefficients become zero and the file shrinks. A coefficient that becomes zero no longer counts as usable, so F5 discards it and fills the group again from the next usable coefficient. That is why one embedding has three different counts: examined (the usable coefficients the embedder looked at), changed (coefficients actually modified) and thrown (modified coefficients that became zero). The number of changes can therefore be larger than the number of groups.

Without a passphrase F5 uses a fixed default permutation key built into the tool (the text StegoToolkit), so the coefficient order is the same for every file and the Extractor needs no input. This default key gives no secrecy against anyone who knows the tool, and it is not an encryption key. With a passphrase the permutation key is the SHA-256 hash of the passphrase and the order depends on it. That SHA-256 step only sets the coefficient order; the AES-256-GCM key is derived separately from the same password with PBKDF2-HMAC-SHA-256 (100,000 iterations), so SHA-256 alone is not what protects the message. In this tool a password does two things: it seeds F5's order and it encrypts the message, a separate layer applied before F5 sees the bytes. The order by itself is not encryption: it hides no secret, and anyone can try passphrases against it.

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 4-byte length counted in those 48 bytes is the encryption envelope's own internal length (the length of the ciphertext including its 16-byte tag). It is separate from the length field of the embedding method (JSteg's 4 bytes, F5's 2 or 3), which is not part of the 48 bytes. The table Stored Layout by Method shows both.

Reed-Solomon is in Forensic mode, in the section Error Correction (Reed-Solomon), with the choices None, RS-10, RS-20 and RS-30. A level adds a 16-byte header and, for every block of up to 223 bytes, 10, 20 or 30 parity bytes, and repairs up to 5, 10 or 15 changed bytes in each block. It is applied to the stored bytes after encryption, so it repairs the ciphertext before it is decrypted. The capacity bar already includes the extra bytes. The 16-byte header is not itself error-corrected (it stores the length twice), and the F5 or JSteg length field, the one-byte flag and the Comment or APP text header are outside the Reed-Solomon wrapper.

Reed-Solomon fixes a few changed bytes. A re-save, resize or re-encode changes almost every coefficient and destroys the data, whatever the level. When damage is beyond the limit the Extractor reports how many blocks it could not repair and shows those bytes as found; with a password the authentication check then fails and you see a decryption failure instead of wrong text. The Extractor page describes the same steps in reverse.

There are two separate features, both only in Forensic mode, and the Extractor has a matching control for each. (1) Plausible Deniability Mode, a switch in the F5 options: the JPEG Comment holds a harmless decoy sentence (default: Shot with Canon EOS R5) and the real message is hidden with F5 under your passphrase, encrypted, without this tool's usual flag byte. It needs a passphrase, and the Extractor finds it only with Deniability Mode (F5) switched on and the same passphrase. (2) The panel Plausible Deniability — Decoy + Real Payload: a plain-text Comment as the decoy, and an AES-256-GCM encrypted real payload hidden with JSteg (never F5, because one wrong ciphertext bit would fail the authentication). The decoy needs no password; the real layer needs the passphrase.

Neither feature writes this tool's header, so Auto-Detect does not find either one (checked in the tests), and a wrong passphrase simply fails: for the first feature the Extractor says the passphrase is wrong or there is no deniability-mode payload; for the second it still shows the decoy and says the real layer could not be decrypted. Deniability here means the file can be explained by the decoy; it does not stop someone who looks for hidden data from finding it, and F5 and JSteg data is still lost if the JPEG is re-encoded.

A JPEG marker segment stores its length in 16 bits, so one Comment or APP segment holds at most 65,533 bytes of content. The tool writes a text header and the Base64 of your stored bytes, which leaves 49,134 bytes for Comment and 49,128 for APP Extension without a password, and 49,080 and 49,077 with one (the 48 bytes of encryption count against the same segment). A larger payload is refused with a message instead of producing a file that cannot be read back.

F5 and JSteg keep the EXIF, ICC profile, Adobe and quantization-table segments byte for byte in our tests, and the picture size and colour layout stay the same. Restart markers are not preserved: F5 and JSteg rewrite the file without them. The output keeps the picture size and colour layout, but F5 and JSteg change some quantised coefficients, so some decoded pixel values differ slightly (see the measurements below). Comment and APP Extension add one segment and leave every other byte of the file as it was. The F5/JSteg engine writes a JFIF header on its own; the tool removes it again when the source had none, because a JFIF header on an RGB-coded Adobe JPEG made decoders read the colours wrongly.