Is Base100 encoding safe for secrets?

No. Base100 is a reversible byte-to-emoji mapping, not encryption. Anyone who knows the 256-symbol range can recover the original bytes, and there is no checksum, MAC, or authentication tag. Use reviewed encryption for any payload you actually need to keep secret.

Why does my pasted Base100 stream fail to decode?

The most common causes are an invisible variation selector such as U+FE0F, a stray space or line break, or a substituted emoji glyph. The strict decoder rejects any code point outside U+1F3F7 through U+1F4F6, so any extra character causes the whole stream to fail. Re-copy from the original source without letting an editor auto-wrap or auto-format the emoji run.

Does Base100 detect tampering?

No. A modified symbol changes exactly one byte downstream, and the format carries no checksum or length marker to flag the change. Use an explicit MAC, a digital signature, or a content hash in addition to Base100 if you need tamper detection.

Can I use Base100 for passwords, tokens, or private keys?

No. Reversible emoji encoding offers zero secrecy and zero authentication, so any sensitive value encoded in Base100 is effectively stored in plain text as soon as someone knows the mapping. For those use cases, use a reviewed cryptographic primitive such as AES-256-GCM.

Where does the encoding actually run?

Encoding and decoding both run locally in your browser using JavaScript. Nothing is uploaded to a server, no account or sign-up is required, and the input is never logged because it never leaves the page.

Base100 Encode Safe: A Byte-Exact Workflow

Base100 encoding is byte-exact and reversible: every UTF-8 byte b maps to a single code point U+1F3F7 + b within the inclusive range U+1F3F7..U+1F4F6, and every conversion runs locally in your browser without uploading the input. That makes Base100 safe for protecting data integrity during a conversion you control — your text never leaves the page, the mapping is deterministic, and the decoder uses fatal UTF-8 validation so invalid bytes produce a clear error rather than a silent replacement character. The same properties also define what Base100 is not: it is not encryption, not hashing, not authentication, and not a steganographic scheme. Anyone who knows the 256-symbol range can recover the original bytes, and a single altered symbol changes exactly one byte downstream with no built-in checksum to flag the change. Treat Base100 as a reversible encoding for transport, display, or puzzle use, and use reviewed cryptography for any payload you actually need to keep secret or to verify against tampering.

What "Safe" Means With Base100 Encoding

The phrase "Base100 encode safe" mixes two different definitions of safety, and the answer depends on which one you mean. Base100 is safe for data integrity during a controlled conversion: every UTF-8 byte maps to exactly one code point in the inclusive range U+1F3F7..U+1F4F6 using the formula code_point = U+1F3F7 + byte, the operation runs locally in your browser, and the decoder performs fatal UTF-8 validation so a malformed stream produces an explicit error rather than a silent replacement character. The same encoding is not safe for secrecy, authentication, or tamper detection — the format was introduced by Adam Niederer's Base100 project as a reversible byte-to-symbol mapping, and anyone who knows the 256-symbol range can recover the original bytes.

Property	Base100
Encryption	No
Hashing or fingerprinting	No
Authentication / digital signing	No
Built-in checksum or MAC	No
Compression	No
Steganography	No
Human-language emoji translation	No
Reversible byte-to-symbol mapping	Yes
Local browser processing (no upload)	Yes
Fatal UTF-8 validation on decode	Yes
Strict range enforcement (U+1F3F7..U+1F4F6)	Yes

Two consequences follow. First, a changed symbol changes exactly one byte downstream, but Base100 carries no checksum, length marker, or MAC, so a syntactically valid edit cannot be distinguished from the original. Second, the same mapping makes the format extremely robust when you preserve the code points exactly, because every conversion is deterministic and every invalid input is rejected loudly. Safety, in this format, is a question of which contract you are using.

Why Base100 Conversion Is Safe in Your Browser

The Base100 Encoder / Decoder implements the mapping entirely in client-side JavaScript, which means the bytes you type never leave the page during encoding or decoding. There is no network request carrying your plaintext, no server-side log, and no telemetry wrapping the conversion. The encoder first turns your JavaScript string into UTF-8 bytes using the same algorithm specified by the WHATWG Encoding Standard that every modern browser applies at its text boundaries, then adds U+1F3F7 to each byte value.

The decoder mirrors that process by iterating over Unicode code points (not UTF-16 code units), rejecting anything outside U+1F3F7..U+1F4F6, subtracting U+1F3F7 from each accepted code point to recover a byte, and then handing the byte stream to a strict UTF-8 decoder that fails on invalid sequences instead of silently substituting U+FFFD. Both directions are bounded to 500,000 bytes or symbols per request, so a runaway paste cannot freeze the tab, and empty input is rejected so you never receive an empty success message by accident. Independent fixtures in the implementation lock the lower and upper code points plus representative byte offsets, so the byte-to-emoji formula behaves identically on every supported browser.

Common Ways a Base100 Stream Gets Corrupted

Most failed round-trips are not caused by the encoder — they are caused by the trip between the encoder's output and the decoder's input. Several classes of edits are common enough to deserve explicit names.

Variation selectors. Some chat apps, keyboards, and emoji pickers insert U+FE0F (variation selector-16) right after an emoji to force a colorful presentation. The added code point is invisible on screen but moves the stream outside the strict Base100 range, and the decoder will reject it.
Spaces, tabs, and line breaks. Word processors, Markdown editors, and code-block formatters routinely wrap long emoji runs at fixed widths or insert zero-width spaces. None of those characters are framing syntax in Base100; they all count as invalid symbols.
Substituted glyphs. Some instant-messaging clients replace unfamiliar emoji with their own pictograph set or downgrade them to monochrome text. A code point that looks like a mapped symbol on screen may actually be a compatibility character from a different block, and the strict decoder will reject the swap.
Normalization pipelines. NFC and NFD do not split or merge Base100 symbols because every mapped code point is a single scalar value, but a paste path that runs through a compatibility-normalization pipeline can still rewrite variation selectors or strip them entirely.

The fix is the same in every case: paste from a source that preserves the original code points, and if a paste fails strict decoding, treat the failure as a code-point mismatch rather than as a Base100 bug.

How to Base100 Encode and Decode Safely

Open the Base100 Encoder / Decoder in a desktop or mobile browser. No install, no sign-up, no server round-trip.
Choose Text to Base100, type or paste your UTF-8 text into the input area, and run the encoder. The encoder converts the string to UTF-8 bytes and maps each byte to one code point in U+1F3F7..U+1F4F6.
Copy the resulting symbol stream with the platform's plain copy action. Do not paste through a rich-text editor first, do not add spaces or line breaks, and do not let the editor auto-wrap the run.
To recover the original text, choose Base100 to text, paste the unmodified stream, and run the decoder. The decoder scans by Unicode code point, rejects anything outside the 256-symbol range, subtracts U+1F3F7 from each accepted code point, and runs a strict UTF-8 pass on the recovered bytes.
If the decoder reports an error, the most likely cause is a variation selector, a hidden space, or a substituted glyph. Re-copy from the original source and retry before assuming the data itself is wrong.
For very large pastes, stay under the 500,000-byte or 500,000-symbol ceiling. If you need to encode more, split the input into independent chunks and concatenate the recovered chunks later — Base100 has no built-in framing, so concatenation is the standard way to join streams.

If you want to see the math behind each step, the worked-through byte-to-emoji formula is detailed in Base100 Encode Explained: The Byte-to-Emoji Formula.

Worked Example: One Byte, One Code Point

Take the ASCII letter A. Its UTF-8 byte value is 65 (0x41). Applying the formula gives U+1F3F7 + 65 = U+1F438 (decimal 128056). Round-trip it through the decoder: U+1F438 - U+1F3F7 = 65, and 65 is a valid single-byte UTF-8 sequence for A. The mapping is therefore lossless for the byte itself; the only way a round-trip can fail is if the code point is altered along the way.

Interoperability Risks Across Apps and Platforms

Base100 symbols live in a supplementary-plane emoji block, which means they are technically valid Unicode but are sometimes handled specially. macOS, Windows, Android, iOS, and Linux distributions each ship their own emoji font, and the same code point can render as a colorful pictograph, a monochrome glyph, a tofu box, or a domain-specific icon. Rendering is purely a presentation concern — the underlying code points do not change — but rendering pipelines that edit characters are a different story.

Several concrete transport scenarios reduce safety:

ASCII-only channels. Email gateways, HTTP headers, URL paths, and some legacy APIs strip or escape any code point outside ASCII. If your destination cannot carry U+1F3F7..U+1F4F6 unchanged, pick a transport-safe encoding such as Base64 or hexadecimal instead.
Markdown and code fences. Some renderers normalize whitespace inside fenced blocks, which inserts the very U+0020 and U+000A characters the strict decoder rejects. Treat fenced code as display-only and use a plain-text channel for transport.
Cloud paste services. Online clipboards sometimes run HTML-to-text conversion that strips variation selectors but also drops the original code-point order. A round-trip through such a service is not guaranteed to survive.

A practical safety rule: when interoperability matters, transport the Base100 stream as plain UTF-8 in a tool that preserves code points exactly, then decode at the destination with the same browser-only decoder.

What Base100 Will Not Protect

Base100 is an encoding, not a security control. It will not hide a password, prove a message came from a particular sender, detect that a stream was tampered with, or compress anything. Anyone with the mapping can recover the original bytes, and a single changed symbol changes exactly one byte downstream with no built-in checksum to flag the change. For secrecy, use reviewed encryption such as the AES Encryption Online tool, and for tamper detection use an authenticated format or an explicit MAC.

The same boundary applies to operational safety. Base100 will not protect against pasting the wrong stream into the wrong window, against a colleague editing the stream without telling you, or against an editor that silently normalizes emoji. The strict decoder helps by rejecting any of those situations loudly instead of pretending the output is exact, but loud rejection only matters if you actually read the error.

Used inside its contract — as a reversible, byte-exact, locally processed emoji mapping with fatal UTF-8 validation — Base100 is one of the safest reversible encodings you can run in a browser. Used outside that contract — as a secrecy layer, a checksum, or a guaranteed-clean transport — it is unsafe by design, and no amount of careful tool choice will change that. Pick the right tool for the right job: Base100 for byte-exact reversible emoji encoding, and a cryptographic primitive for anything you actually need to protect.