ImageSteg · Hide Data Inside an Image or an Audio File

Yes. Hiding and revealing data is free, with no signup, no watermark and no artificial file size limit.

No. Decoding, embedding, compression and encryption run locally in your browser with JavaScript and WebCrypto. Nothing is sent to the 73hi server.

Any image your browser can decode can be a pixel cover, and baseline or progressive JPEG files go through steghide's DCT branch. The output format follows the cover: JPEG in, JPEG out; a pixel cover gives a BMP plus a PNG copy. The steghide command line tool reads the BMP and JPEG outputs, but not PNG.

In the quantised DCT coefficients, exactly like the steghide command line tool. The page includes a JPEG entropy codec that decodes the scan as far as the coefficients, modifies their parity and re-encodes them.

Yes. Progressive files are decoded through their whole scan sequence — spectral selection and successive-approximation refinement — and are written back the same way, so the result is still a progressive JPEG carrying the original coefficients.

Supported for reading. Files using QM (binary arithmetic) coding instead of Huffman — SOF9 for sequential, SOF10 for progressive — are decoded through the same arithmetic decoder libjpeg itself uses, so the coefficients come out identical. The result is written back with Huffman coding, the way steghide does.

Roughly one byte of payload for every eight pixels, minus room for the header, the stored file name and the optional encryption overhead. The tool shows the usable capacity once you pick an image.

Yes, if you download the BMP. The bit layout, the passphrase based sample permutation and the Rijndael/CBC encryption follow steghide 0.5.1.

The payload is stored in individual pixel values. Re-compressing, resizing, filtering or converting to a lossy format such as JPEG destroys it. Keep the original BMP or a lossless PNG copy.

Not by embedding twice into one file. A second pass picks its own random positions across the whole cover and overwrites part of the first payload, and because the data is compressed before it is encrypted, a handful of flipped bits makes the whole message unreadable — you lose it completely, not partially. The original steghide command line tool behaves the same way. Reusing the same passphrase is no better: it rewrites the same positions from the start, so only the newest message survives. For real layers, nest files instead — hide the first secret in a small image, download that result, then hide that whole file inside a larger image under a second passphrase. Each layer stays byte-for-byte intact because it travels as protected data rather than as modified pixels.

No. Loading a file only reads its bytes: JPEG covers go straight to the quantised DCT coefficients with no inverse transform or re-quantisation, and pixel covers are decoded losslessly, so the hidden data survives untouched. A JPEG may be saved at a slightly different file size because the entropy coding is rewritten, but that does not affect the payload. You can safely open a file prepared by someone else and reveal what is inside.

Yes. Embed your copyright notice or ownership proof directly into the photo. The data lives in the pixels (or JPEG coefficients) and stays invisible during normal viewing, so you can share the image publicly without anyone noticing. If someone reuses it without permission, the hidden mark is still inside the file — and when you publish the same image on a third-party platform to document the infringement, that posted copy carries your proof too, giving you solid evidence to support a takedown or a claim.

Absolutely. Hide a message like "I love you" — or anything hard to say face to face — inside an ordinary photo from your daily life, and set the passphrase to the recipient's birthday. Send them the photo and ask them to open it on ImageSteg (or visit 73hi.com/image-steg.html) to unlock it. Only someone who knows the passphrase can reveal the words, so you can express yourself without the awkwardness of saying it out loud.