Whitespace Steganography Hider

Every method turns the message into bits and writes each bit as a choice between two whitespace forms that look the same. Ahead of the message the tool writes a 9-byte header ("WSST", version, method, flags, length, checksum), so the Extractor can find the method on its own. For these four methods the header uses 72 bits; the capacity shown is the bits the method offers in your cover minus those 72, divided by 8 and rounded down to whole bytes. The capacity function looks only at the cover text and the method; a file name, compression and a password change how many bytes are stored (the form's capacity bar accounts for them, and a password adds 48 bytes of encryption overhead). The header's length field is 16 bits, so the stored payload — measured after the file-name frame, compression and encryption, not your original message — can be at most 65,535 bytes, whatever the cover size.

Examples from the tool's own capacity function: a 30-line cover text with 50 characters per line holds 17 bytes with Trailing Space/Tab (7 bits per line) and 0 bytes with Line Ending (its 29 line breaks are fewer than the 72 header bits). A 100-word paragraph holds 3 bytes with Inter-Word Spacing. 100 source lines indented 4 columns hold 3 bytes. The SNOW-style raw format spends one bit per line on a tab marker and 32 bits on a length, and has no 72-bit header. For the same 30-line cover: 30 lines × 7 bits = 210 bits; minus 30 marker bits = 180 bits; minus the 32 length bits = 148 bits; 148 ÷ 8 rounded down = 18 bytes.

Trailing Space/Tab holds the most per line and is the one a trim-trailing-whitespace setting removes; use it when the file will travel unchanged. Inter-Word Spacing needs plenty of words and a text that is not reflowed. Line Ending needs one line break per bit, so it suits long, many-line files. Tab Indentation needs code with indents of 4 columns or more: lines indented by 2 columns are skipped, so a 2-space YAML file offers fewer lines than it appears to have.

Auto tries Trailing Space/Tab first, then Tab Indentation for code, then Inter-Word, then Line Ending, and uses the first that fits. If nothing fits it shows the closest method and says how much is missing.

Only whitespace changes, but more than the bits you embed. Trailing Space/Tab changes every line of the file, including lines beyond the message: it removes any trailing whitespace the cover already had and converts CRLF line endings to LF everywhere. Inter-Word Spacing rewrites every gap of one or two spaces up to the end of the message (a gap that was already a double space can become a single space). Line Ending rewrites the breaks the message uses and drops stray carriage returns on those lines. Tab Indentation rewrites the indent of every line it uses and keeps its width, measured in columns with tab stops every 4 columns (a tab after spaces moves to the next multiple of 4); mixed tab-and-space indents were tested for this. For the last three methods, lines or gaps beyond the message are left exactly as they were.

One thing was measured: with Git 2.54 on macOS and default settings, a commit and checkout kept trailing spaces and tabs, double spaces and CRLF line endings byte for byte. With core.autocrlf set to true or input, Git converted CRLF to LF on commit, which would erase the Line Ending method. Everything else in the survival list is what the relevant setting does by design (an editor that trims trailing whitespace on save removes Trailing Space/Tab; a code formatter rewrites indentation). Whether a chat app, Google Docs or a CMS keeps whitespace has not been tested here, and the table says unknown. Copy the text back out of the app and decode it before relying on it; sharing the downloaded .txt file unchanged is the safe route.

Forensic mode adds a two-layer option: a plain-text decoy is written as Trailing Space/Tab and an encrypted real payload as Inter-Word Spacing, both without a header. Someone who decodes the trailing whitespace in the decoy layout gets the decoy; the real layer needs the password and the Extractor's decoy-decode section. This is concealment, not secrecy: both layers can be found by anyone who inspects the whitespace.

The SNOW-style raw format borrows SNOW's idea — hidden data in trailing whitespace, each data line starting with a tab marker — but it was written independently: its own bit packing (space = 0, tab = 1 after the marker, a 32-bit length) and no ICE cipher. No file was exchanged with the real snow program in a test, so do not expect files to open in either direction. Use it for puzzles built with this site's tools; for a file made by the real SNOW, use the real program.