Text steganography uses four invisible Unicode code points — U+2063, U+2064, U+200B and U+200C — to hide a short UTF-8 message inside ordinary-looking cover text, and the resulting string looks identical to the original sentence in most rendered interfaces. The convention applied by the Text Steganography tool is explicit and inspectable: every hidden UTF-8 byte is expanded into eight zero-width code points, framed by an invisible start and end marker, and inserted after the first visible code point of the cover. Reveal mode reads those exact code points back, validates framing, bit count and UTF-8 byte validity, and reconstructs both the original hidden message and the original visible cover. Because the technique relies entirely on default-ignorable Unicode, anyone who knows the mapping can decode the message, and any sanitizer that strips those code points will destroy it. All processing happens in the browser, so neither the cover text nor the secret text is uploaded to a server at any point.
The Four Invisible Code Points at a Glance
Text steganography, in this convention, is built from exactly four code points. None of them produce ink in a typical font, but each carries a defined role inside the framed segment. Memorize this table and the rest of the workflow falls into place.
| Code point | Name | Role in the framed payload |
|---|---|---|
| U+2063 | Invisible Separator | Marks the start of the framed payload segment. |
| U+2064 | Invisible Plus | Marks the end of the framed payload segment. |
| U+200B | Zero-Width Space | Represents a binary 0 bit in the payload. |
| U+200C | Zero-Width Non-Joiner | Represents a binary 1 bit in the payload. |
The convention defines eight payload bits per hidden byte, written most-significant-bit first, so a single ASCII character becomes eight zero-width code points in a row. The two framing markers are written exactly once, around the entire bit run, not around each byte. If you ever see those code points in an unexpected place, treat them as part of the convention and not as ordinary text. Ordinary zero-width characters that fall outside the framed segment stay part of the visible cover and are not interpreted as payload bits, and reveal mode extracts only the first valid framed segment rather than guessing when framing looks ambiguous.
Hide a UTF-8 Message in Cover Text
Open the Text Steganography tool and choose hide mode. The tool performs three actions on every submission, all in the browser: it encodes the hidden message to UTF-8 bytes, expands each byte to eight zero-width code points using the table above, and inserts the framed run after the first visible code point of the cover. The cover cannot already contain the start marker U+2063 or the end marker U+2064, because accepting one would make the payload boundaries ambiguous.
- Type the visible cover text into the cover field. Keep it short enough to leave headroom for the expansion; the tool rejects covers above 100,000 code points.
- Type the hidden UTF-8 message into the secret field. The hidden message is limited to 10,000 UTF-8 bytes; emoji and CJK characters usually take several bytes each, so the apparent character count will be smaller than the byte count.
- Generate the steganographic string and copy the exact output. Do not retype it, and do not let the editor normalize, autocorrect or reformat the result.
- Verify locally by pasting the result back into reveal mode before sending it anywhere. If the recovered hidden message and the recovered cover match the originals, the round trip on this machine is clean.
Reveal a Hidden Message from Pasted Text
Reveal mode is the inverse of hide mode and uses the same four code points. It scans the pasted text for the start marker, checks that every payload character is one of the two bit symbols, requires the bit count to be a multiple of eight, converts the bits back to bytes, and rejects any byte sequence that is not valid UTF-8. Malformed framing produces a clear error instead of guessing at a payload, which protects against silent corruption when one or more invisible characters have been lost in transport.
- Switch the Text Steganography tool to reveal mode.
- Paste the steganographic string exactly as received. Do not trim, reformat, search-and-replace or run it through a "clean text" tool first.
- Read the recovered hidden message and the recovered cover. The recovered cover should match the original visible sentence character for character.
- If extraction fails, compare raw code points between the sent and received strings to identify which application removed or changed invisible characters. A character counter, diff tool or source viewer will reveal the missing bits immediately.
Payload and Cover Limits at a Glance
Two hard caps keep the rendered DOM responsive and the bit count predictable. They apply to a single hide/reveal operation, not to a session.
| Limit | Value | Why it exists |
|---|---|---|
| Hidden message size | 10,000 UTF-8 bytes | Bounds the bit count so DOM rendering stays responsive. |
| Cover text size | 100,000 code points | Bounds the visible string and the position of the framed insert. |
| Bit expansion | 8 invisible code points per hidden byte | One invisible code point per bit, MSB-first. |
| Framing cost | 2 invisible code points per payload | One start marker (U+2063) and one end marker (U+2064). |
| Cover restriction | No existing U+2063 or U+2064 in the cover | Existing markers would make payload boundaries ambiguous. |
Worked example: a hidden message of 5 ASCII characters becomes 5 UTF-8 bytes. With 8 bits per byte, the bit run is 5 × 8 = 40 invisible code points. Adding the two framing markers gives 40 + 2 = 42 invisible code points inserted after the first visible code point of the cover. That is the total growth of the underlying Unicode sequence, even though a typical font gives those 42 code points no width at all. If the same message were written in emoji or CJK characters, each visible character typically expands to several UTF-8 bytes, which shrinks the apparent character count well below the byte cap.
Sanitization Risks and How to Verify a Round Trip
The four code points above are all default-ignorable, which means many text-handling systems treat them as removable noise. According to the Unicode Security Considerations report, default-ignorable code points are routinely stripped during normalization, copy/paste, encoding conversion and security scanning. That is exactly the surface area where a steganographic payload lives, so transport failure is a frequent risk for this technique.
Practical categories of channels, ranked by reliability:
- Plain-text editors and terminal copy/paste on a single machine — usually preserve the full Unicode sequence end to end.
- File-based transfer of a UTF-8 file untouched between machines — usually preserves, provided neither end normalizes the file.
- Social networks, email gateways, chat clients and content-management systems — frequently strip default-ignorable code points or replace line endings, even when the visible text looks identical.
- Screenshots, photographs of a screen, and printed copies — cannot carry invisible code points at all, because the code points have no rendered form to capture.
Always run a final reveal on the receiving machine before relying on a delivery. If the recovered hidden message and recovered cover match the originals, the transport worked. If they do not, an intermediate application stripped or rewrote one or more invisible code points and the message is gone.
What Text Steganography Does Not Do
This tool provides concealment of a documented payload, and nothing more. The mapping between UTF-8 bytes and zero-width code points is published above; anyone who detects the framing and bit symbols can decode the message. Steganography does not provide confidentiality, authenticity or integrity, and a third party can also alter the hidden bytes without rendering any visible difference. For sensitive data, encrypt first with a reviewed system — the AES Encryption Online tool in the same category handles authenticated AES-256-GCM in the browser — and use this tool only to wrap the ciphertext in cover text for puzzles, demos or sanitization tests. Do not use it to hide credentials, harmful instructions, personal data or material that violates a platform's rules. For durable data exchange, prefer visible encodings or an authenticated file format.
For a deeper look, see How to Convert Text to Binary Code: Byte-Exact UTF-8.