A text steganography API alternative is a browser-side tool that hides a UTF-8 message inside ordinary-looking cover text using zero-width Unicode characters, so no server call, API key, or upload is required. The Text Steganography tool at Lizely applies a documented convention: each UTF-8 byte becomes eight invisible bits, with U+200B (zero-width space) representing binary zero and U+200C (zero-width non-joiner) representing binary one. The bit sequence is wrapped by an invisible separator U+2063 at the start and an invisible plus U+2064 at the end. The framed segment is inserted after the first visible code point in the cover, so the rendered sentence usually looks identical even though the underlying code-point sequence is much longer. Reveal mode reads the markers back, checks that the framed content is a multiple of eight bit symbols, rejects malformed bytes, and returns both the recovered hidden text and the restored visible cover. Because every step happens in the browser, neither the cover nor the secret leaves the device.
The convention is explicit on purpose. A reader who knows where to look can decode it as easily as the tool itself can, which is exactly why the page is presented as a learning and testing surface rather than a confidential one.
A Local Text Steganography Alternative to a Remote API
Most public text-steganography APIs accept a payload, return a steganographic string, and require a network round trip for every hide or reveal request. That model introduces three friction points that a local tool removes: the request sends the secret to someone else's server, the API can disappear or change its contract, and the latency of a remote call adds up when you are testing or iterating on long cover texts. A browser-side alternative keeps the round trip inside your own tab, leaves no audit trail on a third-party host, and keeps working after the initial page load even if your network drops.
It also makes the convention inspectable. Every marker, bit symbol, and limit is described on the page itself, so you can audit the encoding rather than trusting an opaque remote service. For developers maintaining pipelines that already call a steganography endpoint, a local tool is a useful second channel. You can stage a cover, generate the steganographic string, and paste the result into a chat window, an email draft, or a documentation block to test whether the destination preserves the invisible code points — without spending API credits on every experiment. The Text Steganography page exposes hide and reveal modes side by side, so the same convention can be exercised in both directions inside one tab.
How the Zero-Width Convention Hides a UTF-8 Message
The encoding is built from four Unicode characters that are default-ignorable in most fonts: U+200B, U+200C, U+2063, and U+2064. The first two are the binary alphabet; the last two are the framing pair. The hidden message is converted to UTF-8 bytes, each byte is expanded to eight bits in most-significant-bit-first order, and each bit is replaced by its matching zero-width code point. The result is wrapped with U+2063 at the start and U+2064 at the end, so reveal mode can locate the payload even if the cover already contains stray zero-width characters. The framed segment is then inserted after the first visible code point in the cover. Ordinary zero-width characters that were already present in the cover remain in place and are not confused with payload bits, because reveal mode only reads content between the framing markers.
| Aspect | Remote API steganography | Text Steganography (local browser) |
|---|---|---|
| Where the secret is processed | Sent to the API host over HTTPS | Stays inside the browser tab |
| Network requirement | Required for every hide or reveal call | Required only for the initial page load |
| Mapping documentation | Usually proprietary or hidden | Every marker and bit symbol is listed on the page |
| Failure mode after sanitization | Often silent; you trust the API | Reveal mode returns an explicit framing or UTF-8 error |
| Limit disclosure | Depends on the provider's docs | 10,000 hidden UTF-8 bytes, 100,000 cover code points |
| Confidentiality guarantee | Whatever the provider claims | None — concealment only, not encryption |
Hide a Message in Cover Text
How to hide a short UTF-8 message inside cover text using Text Steganography:
- Open the Text Steganography page and switch to hide mode.
- Type an ordinary cover sentence in the cover field — the visible text that will carry the hidden payload.
- Type the secret message in the hidden field. Count each emoji or non-Latin character as multiple UTF-8 bytes; the limit is 10,000 bytes.
- Generate the steganographic string. The framed invisible sequence is inserted after the first visible code point of your cover.
- Copy the exact result. Do not retype it, do not run it through autocorrect or smart-quote replacement, and do not save it as a stripped-text file.
- Paste it into a destination that preserves zero-width Unicode, such as a plain-text editor, then reveal it again on the same page to confirm the round trip before you rely on delivery.
The generated string is what recipients need to see — visually it is the same sentence you typed. On the receiving end, paste the exact characters into reveal mode. Do not edit, trim, or clean up whitespace first, because a single dropped bit turns the rest of the payload into invalid UTF-8.
Reveal a Hidden Message After Transport
How to extract a hidden UTF-8 message from a steganographic string:
- Open Text Steganography and switch to reveal mode.
- Paste the exact steganographic text. Do not paste from a screenshot, a printed copy, or a transcription — invisible code points cannot survive those channels.
- Read the recovered hidden message and the restored visible cover that the tool returns.
- If extraction fails, compare raw code points between the generated string and the received string. The application that received your paste probably normalized or stripped default-ignorable characters.
- For a quick audit, copy the steganographic string into a Unicode code-point viewer such as the Unicode Encoder / Decoder; any zero-width characters will show up as U+200B, U+200C, U+2063, or U+2064.
Reveal mode performs three checks: it locates the start and end markers, requires that the framed content is a multiple of eight bit symbols, and rejects byte sequences that are not valid UTF-8. Malformed framing is treated as an error rather than guessed, so you get a clear signal when transport has damaged the payload instead of silently decoding garbage.
What Can Break the Hidden Payload During Transport
Steganography depends on the carrier surviving transport unchanged, and many platforms do not respect zero-width characters. Social networks frequently filter default-ignorable code points, email gateways can normalize line endings and strip invisibles, content-management systems re-serialize pasted HTML, chat clients may collapse or rewrite whitespace, and clipboard managers on some operating systems strip control-format characters. Per the Unicode Consortium's security considerations, default-ignorable characters are routinely removed or rendered inconsistently across implementations, which is exactly the risk surface this convention sits on. The honest framing is: this is concealment that is easy to detect and easy to break, not a confidential channel.
A practical defense is to test the full path before relying on it. Generate the steganographic string, paste it into the destination you intend to use, copy what comes back, and reveal it on the same page. If the round trip fails, the destination has sanitized your payload and you need a channel that preserves Unicode exactly — usually a plain-text editor, a code-friendly chat, or a file attachment sent unchanged. Screenshots and printed copies cannot carry invisible code points at all.
Limits, Scope, and What This Tool Does Not Replace
The hidden message is capped at 10,000 UTF-8 bytes and the cover at 100,000 code points. Those caps keep bit expansion and DOM rendering responsive, because every hidden byte becomes eight additional code points plus framing, and emoji or non-Latin characters can occupy several UTF-8 bytes each, so the hidden character count is smaller than the byte limit. The cover must not already contain the start or end marker used by this convention, because accepting one would make payload boundaries ambiguous. Reveal mode extracts only the first valid framed segment and treats malformed framing as an error rather than guessing.
This is concealment for demonstrations, puzzles, and sanitizer testing, not a cryptographic secret channel. The mapping is documented and easy to detect once a reader knows to look for the bit symbols, so anyone who knows or guesses the convention can decode the message, and anyone who can edit the cover can alter the payload. For anything sensitive, encrypt the payload with a reviewed system such as the AES Encryption Online tool before embedding it, and treat the steganographic string as a casual carrier rather than a secure envelope. For durable data exchange that must survive arbitrary sanitizers, prefer a visible encoding such as the Base64 Encode / Decode tool, or an authenticated file format.