Text Steganography Hider

You paste a cover text (the text people will see), type a message or pick a file, and the Hider returns the same text with the hidden payload encoded into characters that most readers do not notice: look-alike letters, Unicode space characters, or the number of spaces and tabs at certain places. Nothing is hidden by a password alone; encryption is an optional extra described below.

There are four methods and each changes the text differently. They are not interchangeable: a service that rewrites spaces destroys the three whitespace methods, and a service that rewrites letters destroys Homoglyph. We have not tested any individual website or app, so choose the method by what your destination is likely to keep, then paste the text back through the Extractor to check.

Homoglyph replaces some of the letters a e o p c x y C L I with a different character that looks the same: Cyrillic а е о р с х у (U+0430, U+0435, U+043E, U+0440, U+0441, U+0445, U+0443) and the Roman numerals Ⅽ U+216D, Ⅼ U+216C and Ⅰ U+2160. A 1 bit swaps the letter, a 0 bit keeps it. The text looks largely unchanged but those letters are now different code points, which a code-point or search view shows immediately, and a cover that already contains any of these characters is refused because they would be read as 1 bits.

Unicode Whitespace replaces eligible ASCII spaces with one of four Unicode spaces, two bits per space: 00 thin space U+2009, 01 hair space U+200A, 10 en space U+2002, 11 em space U+2003. Trailing Whitespace puts one space (0) or one tab (1) at the end of a line, one bit per line, and removes any trailing spaces and tabs the line already had. Inter-Word Spacing writes a single space (0) or a double space (1) between words, one bit per gap.

The whitespace methods rewrite whitespace that was already in your cover: Trailing Whitespace strips existing trailing spaces and tabs on every line (including lines after the message ends), and Inter-Word Spacing treats existing double spaces as 1 bits. Review the result if the cover is code, a table or a poem where spacing matters.

The payload is optionally encrypted with AES-256-GCM, then optionally wrapped with Reed-Solomon parity, then given a 4-byte big-endian length in front, and the bytes are written most-significant bit first, one bit (or two for Unicode Whitespace) per position in the order the positions appear in the text. An unencrypted payload has no checksum or authentication tag (an encrypted one has the AES-GCM tag). The Extractor accepts a frame when the length it reads fits in the available text, so an altered unencrypted message can be returned with incorrect bytes.

Capacity is therefore (positions ÷ 8) − 4 bytes for a plain message, less 48 bytes when a password is set (the encrypted layout has its own 4-byte length, a 16-byte salt, a 12-byte IV and a 16-byte tag, separate from the outer 4-byte length) and less Reed-Solomon parity (16 header bytes plus 10, 20 or 30 per 223-byte block). A cover that is too short is refused with the exact number of bits it needs; a 2-byte message needs 48 bits (32 length bits plus 16 message bits).

Homoglyph usually changes the fewest visible characters (it depends on the cover text and the payload) but puts non-Latin letters into Latin text, and a copy that goes through NFKC normalisation converts the Roman numerals back. Unicode Whitespace encodes up to 2 bits per eligible ASCII space, the most per position of the four methods, though total capacity still depends on the cover (on the prose cover below Homoglyph holds slightly more) and it is lost when a tool replaces Unicode spaces or applies NFKC. Trailing Whitespace needs many lines for even a short message and does not survive an editor that trims line ends. Inter-Word Spacing survives only as long as double spaces are kept.

None of the four has been measured against detection tools, and none has been tested on a specific service. The Extractor's Anomaly Score shows how unusual a text looks by counting these same features; it is not a detector for a particular method.

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.