QR Code Steganography Hider

You give the tool the link or text the QR code should say. It draws a standard black-and-white QR code for that content (error-correction level L, M, Q or H; each module 3, 5, 8 or 10 pixels wide; a 4-module quiet zone) and hides your message in the PNG with the method you choose. Any QR reader reads the link as usual; the hidden message is only found by something that looks for it, such as the QR Code Steganography Extractor.

This page is for hiding a message in a QR image. For other pictures use the Image Steganography Hider or the LSB Embedder; to check an image you did not make, use the Steganography Detector.

PNG Metadata stores your bytes, as Base64 text with a 4-byte length in front, in a PNG tEXt chunk with the keyword stego, placed after the IHDR chunk. No pixel changes at all. Any metadata viewer shows the chunk, and saving the image again with a program that rewrites PNG chunks removes it. The 4,096-byte limit counts the stored bytes (your message after the password and Reed-Solomon), before the 4-byte length and the Base64; the table PNG Metadata: Largest Message shows what that leaves for the message.

LSB Pixel Encoding writes your bytes into the lowest bit of the red value of the first pixels, in reading order (top row first, left to right), after a 4-byte length. A pixel only changes when its bit differs from what is there: in the first example below, 77 of the 136 bits needed a change. Because embedding starts at the top-left pixel and proceeds in reading order, the modified pixels form a consecutive region beginning in the quiet zone and extending into subsequent QR rows as the payload grows.

Module Color Steganography changes one pixel per data module: the pixel in the middle of the module. A dark module's red value goes from 0 to 1 (bit 1) or 2 (bit 0); a light module's from 255 to 254 (bit 1) or 253 (bit 0). Modules are used in reading order (row by row, left to right) after a 4-byte length. The modules that carry no bits are the 9 × 9 block in the top-left corner (rows 0 to 8, columns 0 to 8: finder pattern, separator and format information), rows 0 to 8 of the last 8 columns in the top-right corner, the last 8 rows of columns 0 to 8 in the bottom-left corner, and all of row 6 and column 6 (the timing patterns). Alignment patterns and version-information blocks are not excluded. The QR matrix is unchanged, so readers see the same code. The capacity is the data modules divided by 8, rounded down, minus the 4-byte length (see the table Module Color: Data Modules and Capacity).

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.

In this tool the password protects the hidden payload only. The QR code itself, and the link or text it scans to, is not encrypted: any QR reader still reads it exactly as before.

Order matters: your message is encrypted first (if you set a password) and the Reed-Solomon wrapper is put around the encrypted bytes. The Extractor removes the wrapper first, repairs what it can, and then decrypts. The wrapper is 16 bytes plus 10, 20 or 30 parity bytes for every 223 bytes of data, so 223 bytes become 249, 259 or 269. It repairs scattered changed bytes, not an image that was re-saved as JPEG, resized or photographed.

Two different error-correction systems are involved and they do not overlap. The QR code has its own error correction (levels L, M, Q and H) built into the code: it helps a scanner recover the QR content, the link or text, from a damaged or dirty code, and it does nothing for the hidden bytes. The Reed-Solomon option here is applied to the hidden bytes only: it can repair changed bytes in the hidden payload, and it does not help a scanner read the QR. Choosing error-correction level H does not protect the hidden message.