Hiding text inside other text means embedding an invisible UTF-8 message into a normal-looking sentence by inserting zero-width Unicode characters that a font renders with no visible width, so the cover sentence still reads the same to the eye while secretly carrying up to 10,000 bytes of additional data between its code points. The technique is a form of text steganography — the payload is concealed, not encrypted — and it relies on the fact that Unicode reserves several formatting code points whose presence does not move the cursor. Each hidden UTF-8 byte is written as exactly eight invisible bits, framed by two more invisible markers, and the framed sequence is inserted immediately after the first visible code point of the cover. A recipient who has the same tool can paste the exact string back in and read both the secret message and the original cover sentence. The catch is transport: any sanitizer that strips default-ignorable code points can drop the payload before the reader ever sees it. For that reason, every step from the cover to the recipient should be tested end to end before relying on the message.
What Zero-Width Steganography Actually Does
Text steganography is the practice of smuggling a second message inside a piece of text that still appears normal on screen. The version used by Text Steganography achieves this by hiding a short UTF-8 string inside an arbitrary cover sentence using only zero-width Unicode characters. The visible sentence still reads as the original cover, but its underlying code-point sequence now contains an invisible framed block that any compatible decoder can extract.
The transformation is local and transparent. All encoding and decoding happens in the browser, so neither the cover nor the secret is uploaded anywhere. The tool does not advertise compatibility with other steganography websites; instead it documents an explicit convention with named markers, two bit symbols, and a fixed insertion point. Because the mapping is open, the result is concealment, not cryptography. Anyone who knows or detects the convention can read the hidden message, and anyone who edits the string can alter it. Encrypt sensitive material first, then hide the ciphertext if both secrecy and plausible deniability matter.
How the Marker Convention Works
The convention reuses four Unicode code points that default fonts render with zero width. They are not invented for this tool; they are part of the standard general-category set and their semantic roles come from this tool's documented mapping.
| Code point | Name | Role in this convention |
|---|---|---|
| U+200B | Zero-Width Space | Represents a binary 0 |
| U+200C | Zero-Width Non-Joiner | Represents a binary 1 |
| U+2063 | Invisible Separator | Marks the start of the payload |
| U+2064 | Invisible Plus | Marks the end of the payload |
Each hidden UTF-8 byte is expanded into eight bits in most-significant-bit-first order. The byte 0x41, which encodes the ASCII letter 'A', is therefore the bit sequence 0 1 0 0 0 0 0 1, rendered as the invisible string ZWS–ZWNJ–ZWS–ZWS–ZWS–ZWS–ZWS–ZWNJ. Once the full byte sequence is written, an Invisible Separator is placed at the front and an Invisible Plus at the back. The whole framed block is then inserted directly after the first visible code point of the cover. Reveal mode reverses the process: it locates the markers, confirms that every character between them is one of the two bit symbols, requires a multiple of eight bits, and rejects any byte sequence that is not valid UTF-8. If you want a deeper look at how bytes map to bits in the first place, the binary-to-text conversion guide walks through the same bit-expansion idea.
Embed a Hidden Message in Cover Text
The tool offers two modes — hide and reveal — and a full round trip is the simplest way to confirm the convention works on your input.
- Open Text Steganography and switch to hide mode. Enter an ordinary cover sentence in the visible field and a separate short message in the hidden field.
- Click the generate control to produce the steganographic string. The rendered output should look like the cover, but it now contains a framed sequence of invisible code points inserted right after the first visible character.
- Copy the exact result through a channel you have already tested for zero-width preservation — a plain-text editor, a code-friendly chat client, or a clipboard that does not auto-sanitize. Avoid screenshots, printed copies, and any route that may strip default-ignorable code points.
- Paste the string into reveal mode without retyping it. Confirm that the tool returns both your hidden message and the exact original cover text. If the extracted payload is empty, garbled, or marked invalid, compare raw code points to find which sanitizer removed the invisible characters.
Why Payloads Vanish After Transport
The convention is deterministic and reversible inside this tool, but the moment a string leaves the browser it crosses systems that treat invisible Unicode as noise. Social networks, email gateways, chat clients, content-management systems, and clipboard managers routinely normalize, filter, or reserialize pasted text. Some strip default-ignorable characters entirely; others replace line endings, normalize confusable code points, or reject the marker characters outright. According to the Unicode security considerations, default-ignorable code points can be ignored by rendering and processing pipelines without changing visible appearance — which is exactly the property that lets the trick work, and the reason it can fail without warning.
If even a single hidden bit disappears during transport, the eight-bit alignment of the payload breaks. A bit lost from the middle shifts every following byte by one position, so the decoder sees a different sequence and either returns nonsense or refuses the result as invalid UTF-8. The remedy is to treat every channel as suspect until tested: send the round-tripped string to yourself first, run reveal mode on what actually arrived, and only trust the channel after it preserves both the secret and the cover byte for byte. Screenshots and printed copies cannot carry invisible code points at all, so they are unsuitable for delivery even when the underlying string would survive.
Limits, Safety, and Honest Expectations
The tool accepts up to 10,000 UTF-8 bytes in the hidden field and 100,000 code points in the cover. Those limits exist because each hidden byte adds eight code points plus two framing markers to the underlying string, and very long payloads would slow DOM rendering in the browser. Emoji and non-Latin scripts often need several UTF-8 bytes per character, so the hidden character count can sit well below the byte cap. If the cover already contains this convention's start or end marker, the tool rejects it — accepting either would make payload boundaries ambiguous. Plain zero-width characters elsewhere in the cover remain part of the visible sentence and are not interpreted as payload bits.
Reveal mode extracts only the first valid framed segment, treats malformed framing as an error instead of guessing, and returns the recovered visible cover alongside the secret. The visible sentence and the recovered cover look identical in a typical font, but their underlying code-point sequences are not equal: a character counter, a diff tool, a source viewer, or a security scanner can expose the extra invisible characters immediately. Treat the result as concealment for demonstrations, puzzles, and sanitization testing rather than a secret channel. For durable data exchange, prefer visible encodings or an authenticated file format so the recipient does not depend on every link in the transport chain preserving a documented zero-width mapping.
Tests in this tool cover ASCII, CJK, and emoji inputs, tab and newline characters, one-code-point covers, empty inputs, reserved markers, absent payloads, and incomplete bytes. Each test asserts both the recovered hidden text and exact restoration of the cover, so the round trip proves this convention's implementation — not survival through an external service. The same round-trip discipline is the right discipline to apply to any channel you plan to use: confirm that the destination receives the framed sequence intact, not just the visible sentence.
For a deeper look, see Describe How to Convert Text to Binary Numbers Step by Step.