PNG Steganography Hider

A PNG file is a signature followed by chunks — IHDR (size and format), optional ancillary chunks such as tEXt or gAMA, one or more IDAT chunks holding the compressed pixel data, and IEND. Four of this tool's five methods use that structure or the pixel data's own bytes instead of changing visible colours: Chunk Injection adds a chunk, EOF Append adds bytes after IEND, Row Filter Encoding picks scanline filter types, and Alpha Channel writes into colours that cannot be seen because the pixel is fully transparent. Only LSB in IDAT changes the colours of visible pixels, by at most 1 out of 255 per value.

Nothing here is encryption on its own. Without a password the payload is stored as plain bytes behind an 18-byte header; the Extractor, or anyone who reads the chunk list, the bytes after IEND or the pixel bits, can find it. With a password the payload is encrypted first, but the header is not, so the file still shows that a payload of a given size and method exists.

Quick mode uses a tEXt chunk. Standard adds EOF Append, the other chunk types (iTXt, zTXt, custom) and deflate compression. Forensic adds Alpha Channel, Row Filter Encoding, LSB in IDAT, Reed-Solomon, IHDR manipulation and a two-layer decoy mode.

Chunk Injection and EOF Append keep every pixel and every other byte of the original file, and in our tests the decoded pixels were identical to the cover. They are also the easiest to find: a chunk list (pngcheck -v) or the size of the file shows them. Importantly, they only survive a byte-for-byte copy of the file. In our tests a plain re-save with the macOS image tool removed them in all 8 photographs, together with Row Filter and Alpha data; only LSB in IDAT survived lossless re-saves (PNG to PNG, BMP and TIFF round trips), and nothing survived JPEG conversion or resizing.

Use LSB in IDAT when the PNG may be re-saved losslessly. Use Alpha Channel only with a cover that already has fully transparent pixels. Treat Row Filter Encoding as a curiosity: it holds 1 bit per row, at most 64 bytes in a 512-row image, so it cannot hold an encrypted payload at all (the header plus AES wrapper alone is 66 bytes).

Every payload is wrapped as an 18-byte header followed by the payload bytes (deflated if you chose that, then AES-256-GCM encrypted if you set a password, then Reed-Solomon parity if you picked a level). The header is big-endian: the magic 'PSTG', a version byte (1), a flags byte (bit 0 encrypted, bit 1 compressed, bits 2–3 Reed-Solomon level), a 2-byte method code, the 4-byte stored length, 2 reserved bytes (0) and a CRC-32 of the first 14 bytes. The CRC-32 detects accidental change; it does not authenticate anything.

Chunk Injection stores that wrapper in one of four forms. tEXt and iTXt hold it as base64 text under a keyword (default 'stegotoolkit'), which makes it a third larger; zTXt holds it deflated; a custom chunk type holds it raw. EOF Append writes it after IEND. Alpha Channel writes one bit into the lowest bit of the red value of each fully transparent pixel, in raster order. LSB in IDAT writes one bit into the lowest bit of R, G, then B of each pixel from the first pixel, in raster order. Row Filter Encoding re-filters each scanline so that the parity of its filter-type byte (0 None, 1 Sub, 2 Up, 3 Average, 4 Paeth) carries one bit; defiltering recovers identical pixel values whichever type is used. It needs a non-interlaced PNG no larger than 512 × 512.

Alpha Channel and LSB in IDAT decode the pixels and write a brand-new PNG with this tool's own writer, so the file's other ancillary chunks (tEXt, iTXt, iCCP, gAMA …) are dropped and the image data is rewritten. Chunk Injection and EOF Append copy the original file's bytes unchanged and only add the new chunk or bytes. Row Filter rewrites the image data but keeps the other chunks.

Capacity is the raw figure for the method minus the 18-byte header, minus 48 bytes if you set a password (4-byte length, 16-byte salt, 12-byte IV, 16-byte tag) and minus Reed-Solomon parity. LSB in IDAT holds width × height × 3 ÷ 8 bytes raw; Alpha Channel holds transparent pixels ÷ 8; Row Filter holds rows ÷ 8. Capacity here means the size of your original payload. The tool stores a larger stream (18-byte header, plus 48 bytes with a password, plus Reed-Solomon parity, plus base64 for tEXt/iTXt), and the bar subtracts all of that for you. The bar's figure is exact when Deflate is off (it cannot predict compression). It is tested equal to what the encoder accepts, and one byte more is refused with a message; this is tested at the exact limit for each method in the table below. Deflate is not predicted by the bar: the encoder checks the compressed size.

Three limits are separate. The carrier PNG you open is limited to 50 MB. The finished PNG must also stay within 50 MB, because that is the largest file the Extractor opens. And each method has its own payload capacity, which is usually far below 50 MB (LSB in IDAT, Alpha Channel and Row Filter are bounded by the image). Chunk Injection and EOF Append add bytes to the file, so their limit is the finished PNG: it must stay within the 50 MB the Extractor accepts (the Hider refuses a larger result with a message, because the Extractor could not open it). That leaves about 50 MB minus the carrier's size for EOF Append and custom chunks, and about 37 MB for tEXt and iTXt because base64 is a third larger. In browser tests a 1 MB, a 40 MB and a 49.8 MB file payload (EOF Append) were embedded, downloaded and extracted again in Chromium, Firefox and WebKit, with the downloaded bytes checked independently. Those size tests used EOF Append only. At the exact displayed limit, EOF Append, tEXt and custom-chunk output round-tripped in an automated (non-browser) test while a payload 2,000 bytes over was refused; iTXt and zTXt were not size-tested.

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.

After embedding, the tool decodes its own output with the Extractor's code and compares the recovered bytes with your payload; if they differ it stops with an error instead of offering a download. The SHA-256 shown in the result is of your payload, for your own records.

Reed-Solomon (RS-10, RS-20, RS-30) adds parity so that scattered changed bytes in the stored data can be repaired; it does not rescue a file that another program re-encoded, because that changes almost every byte. IHDR manipulation (Chunk Injection and EOF Append only) writes a wrong width and height into IHDR with a valid CRC so most viewers show a broken image until the real size is restored; it is a CTF device, not a hiding method, and it is incompatible with the three methods whose decoding needs the true size. The decoy mode writes a plaintext message in a tEXt chunk and an encrypted real payload in the pixels' lowest bits.