GIF Steganography Hider

A GIF does not store a colour for every pixel. It stores a colour table (the palette, at most 256 entries) and then, for each pixel, a number that says which table entry to use. That number is the colour index. This tool's two pixel methods change the lowest bit of those index numbers: an index of 6 becomes 7, or 7 becomes 6, so the pixel points at the neighbouring table entry. If the two entries are similar colours, the change is hard to see. If they are not, it shows.

The third method does not touch pixels. A GIF file is a sequence of blocks, and the format allows Application Extension blocks that readers ignore if they do not recognise them. The Metadata method adds one such block, named STEGANOG, carrying your message. Players show the same picture, but the file is bigger and the block is easy to find in a hex editor.

The output is always a .gif. After the file is rewritten, each frame's delay, disposal method and transparency setting are copied through byte for byte (tested). That is not the same as the picture looking identical: Palette LSB and Multi-Frame change pixel colours, and on a transparent GIF they can change which pixels are transparent (see below). Only the Metadata method leaves every pixel as it was.

Use Palette LSB for a static GIF or a short message. It is the default. Use Multi-Frame Distribution when the GIF is animated and the message is large, because each frame then carries only a share of the bits. On a GIF with a single frame, Multi-Frame has no frames to spread across and offers no capacity, so pick Palette LSB there.

Use Metadata when you want the picture to stay byte-for-byte identical and the message is under 2,000 bytes. It is the most fragile in transit: any optimiser, converter or uploader that rewrites the file may drop the block. It also does not work on GIF87a files, which have no extension blocks, and the tool disables it for them.

For Palette LSB and Multi-Frame the stored stream can be at most floor(total pixels ÷ 8) − 20 bytes, where total pixels counts every frame (Multi-Frame also needs a first frame of at least 96 pixels, because the whole header is written into it; below that its capacity is 0). The stream is a 12-byte header (6 bytes in plausible-deniability mode), then your data. Your data starts with one filename byte, so the largest plain-text message is 13 bytes smaller than the stream capacity. A password adds 48 bytes; Reed-Solomon adds a 16-byte header plus 10, 20 or 30 parity bytes per 223-byte block; Deflate compression can shrink the data, but by how much depends on the data, so the capacity bar only estimates it.

These limits are this tool's own, not limits of the GIF format: they follow from where this encoder puts the bits (one bit per pixel index) and from the header it writes. The bar and the Hide button use the same function the encoder enforces, including the header, the filename byte, a password, compression and Reed-Solomon. A payload that exceeds the capacity is refused with a message rather than cut short, and the boundary is tested: the largest payload the bar allows is written and read back exactly, and one byte more is refused, for every method with and without a password and Reed-Solomon. The encoder's own check is the authoritative one; the formulas here describe it. Sizes on this page are in bytes.

It depends on the message length and on the palette. We measured PSNR (a standard distortion figure; higher means closer to the original) on 480 × 320 GIFs built from photo-like images with Pillow's palette quantiser. They are not real photographs, so treat the numbers as a guide: a 29-byte message gave roughly 55 to 60 dB, a 1 KB message about 36 to 41 dB, and a message filling half the capacity about 28 to 32 dB, with around a quarter of the pixels changing colour. The mean RGB distance between palette entries 2k and 2k+1 on those test files was about 10 to 17 units.

So "hard to see" is true for short messages and not for messages near capacity. After encoding the tool shows the measured PSNR, the number of pixels that changed and the frames modified for your actual file; trust those over any general statement.

Palette LSB and Multi-Frame do not look at the transparency setting. If a frame marks one palette index as transparent, flipping the lowest bit of a pixel's index can move it onto or off that index, which turns a transparent pixel opaque or the other way round. In a test, hiding 300 bytes in a GIF with a transparent index made 638 transparent pixels opaque. The Hider shows a warning when it finds a transparent GIF. Use the Metadata method for such files, or check the result view.

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.

RS-10, RS-20 and RS-30 add parity bytes so that up to 5, 10 or 15 changed bytes per 223-byte block can be repaired. This helps when a few bytes are damaged. It does not help when a file is re-encoded, resized or optimised, because that changes most pixels at once. The Extractor recognises Reed-Solomon data by its header, so you do not need to set the level when decoding.

The "Plausible deniability" switch in the settings leaves the STEGO signature bytes out of the stream, so Auto-Detect cannot recognise the file by that signature. It requires a password, the Extractor needs the exact method chosen by hand, and it does not hide statistical changes from analysis.

The separate Forensic-mode section "Plausible Deniability: Decoy + Real Payload" builds a different thing: an outer decoy message in an Application Extension block and your real payload, AES-256-GCM encrypted, inside the pixels by Palette LSB. Without the password only the decoy is recoverable. Both layers are headerless, so this tool's Auto-Detect does not identify either one. That does not make the data undetectable by other tools or manual inspection; the decoy block is a visible Application Extension block, and statistical tests can flag the pixel changes.

Forensic mode can embed a different recipient identifier in a copy of the GIF for each name in a list, and produce a ZIP of the copies plus a separate watermark_keys.json. It is a way to trace which copy leaked. It is not tamper-proof: anyone who re-saves a copy through an editor or optimiser removes the pixel changes.