Base100 decoding reads a stream of emoji-range Unicode symbols and recovers the original UTF-8 text behind it, using a one-byte-to-one-codepoint mapping across the inclusive range U+1F3F7 through U+1F4F6. The decoder subtracts U+1F3F7 from each symbol's code point to recover a byte between 0 and 255, collects those bytes in order, and runs a strict UTF-8 validator to rebuild the original string. Because the mapping is bytewise and deterministic, anyone who knows the formula can decode a Base100 stream — there is no secret key, no padding, no checksum, and no compression. A base100 decoder therefore has three concrete jobs: accept only unmodified code points inside the exact range, fail loudly on anything outside U+1F3F7 to U+1F4F6, and refuse to guess when the resulting bytes do not form a valid UTF-8 sequence. Modern decoders also operate on full Unicode code points rather than UTF-16 code units, so they correctly handle supplementary plane symbols instead of splitting them into mismatched surrogate halves.
Base100 was introduced as a public byte-to-emoji encoder and the Adam Niederer Base100 repository remains the canonical reference for the mapping. The Base100 Encoder / Decoder applies that same byte arithmetic in the browser, which is why the tool can decode a stream that someone else encoded with the original library without any extra negotiation.
The Byte-to-Codepoint Mapping at the Core of Base100
Every byte from 0 to 255 corresponds to exactly one Unicode code point in the Base100 alphabet, and the formula is simply code point = U+1F3F7 + byte value. Byte 0 becomes U+1F3F7, byte 1 becomes U+1F3F8, and byte 255 becomes U+1F4F6. Decoding is the inverse: subtract U+1F3F7 from the code point to recover the original byte, then concatenate the bytes in input order. Because the alphabet uses contiguous code points, a base100 decoder can validate each symbol by checking that the code point falls inside the inclusive range rather than by pattern-matching against a fixed table.
Encoding always starts by converting the input string to UTF-8, which is the byte sequence the mapping operates on. Ordinary ASCII characters take one byte each, so a string of plain letters produces one Base100 symbol per character. Non-ASCII text usually expands because a single Unicode character can require several UTF-8 bytes — accented letters often need two bytes, CJK characters need three, and supplementary plane characters need four. The output symbol count therefore measures encoded bytes, not grapheme clusters, words, or the original JavaScript string length. For example, the word "Café" is four characters but five UTF-8 bytes, because the accented é encodes to two bytes; a Base100 stream therefore carries five symbols.
There is no framing syntax in the format: no prefix, no delimiter, no length marker, and no checksum. A strict base100 decoder treats every character that is not a code point in U+1F3F7 to U+1F4F6 as an error rather than as a separator to ignore. This is one of the meaningful differences between the original Base100 mapping and many chat-friendly encodings that allow padding or whitespace between symbols.
How to Decode Base100 Symbols Back to Text
If you have a stream of Base100 symbols copied from a message, a file, or a previous encoding step, the Base100 Encoder / Decoder reverses it locally in your browser.
- Open the Base100 Encoder / Decoder and choose the Base100 to text direction so the form expects emoji-range symbols rather than a plain string.
- Paste the symbol stream into the input area exactly as it was copied. Do not retype it, do not insert spaces between symbols, and do not add line breaks.
- Run the conversion. The tool reads each symbol as a Unicode code point, rejects anything outside U+1F3F7 to U+1F4F6, and subtracts U+1F3F7 to recover the byte values.
- Review the decoded text. If the underlying bytes are not a valid UTF-8 sequence, the tool reports an error instead of silently substituting replacement characters.
- Copy the recovered text and reuse it in the destination application.
The same tool runs in the opposite direction when you choose Text to Base100: it converts your UTF-8 string into a symbol stream using the byte formula above, and you can copy the result for sharing. For a closer look at the byte side of the format, see the Base100 encode guide that walks through the UTF-8 byte mapping with worked examples.
Why Pasted Base100 Streams Sometimes Fail to Decode
Because Base100 has no checksum, a stream can be syntactically valid in shape yet bytewise wrong, and a strict decoder is designed to surface that rather than paper over it. The most common failure is a variation selector. Some chat apps, emoji keyboards, and normalization pipelines attach U+FE0F (variation selector-16) or U+200D (zero-width joiner) to emoji-range code points to control their rendered appearance. The resulting symbol looks identical on screen, but the code point sequence is no longer exactly U+1F3F7 to U+1F4F6, and a base100 decoder that enforces the inclusive range will reject the stream.
Spaces, newlines, commas, and other punctuation cause the same kind of rejection. The original format does not use separators between symbols, so any whitespace you copy along with the stream turns into extra code points that fall outside the alphabet. Copying through a word processor that rewraps lines, a terminal that splits output across rows, or a screenshot-to-text OCR layer can all introduce invisible characters that defeat strict decoding.
Rendering quirks also matter. The same code point can appear as a colorful image, a monochrome glyph, an empty box, or an unexpected pictograph depending on the operating system, font, browser, and messaging platform. Rendering differences do not change the code points inside a conforming string, but they do change what you actually copy when you select the text. If the destination requires transport that survives every clipboard transformation, Base64, base64url, Base32, or hexadecimal will usually be more compatible than Base100. For hexadecimal, the WHATWG Encoding Standard defines the UTF-8 boundaries that any conforming decoder has to respect.
Base100 vs Base64, Base32, Base58, and Hex
Base100 is one of several byte-to-symbol encodings, and choosing between them is mostly about the alphabet and the transport. The table below compares the formats on the properties that matter when you copy a payload through a chat app, a code file, or a binary-only channel.
| Format | Alphabet | Padding | ASCII safe | Best for |
|---|---|---|---|---|
| Base100 | 256 emoji-range code points (U+1F3F7–U+1F4F6) | None | No (emoji transport only) | Visually distinct byte streams in emoji-friendly contexts |
| Base64 | A–Z, a–z, 0–9, +, / | = to round length to 4 | Yes | Universal binary-to-text transport |
| Base32 | A–Z, 2–7 | = to round length to 8 | Yes | Case-insensitive, human-typed codes |
| Base58 | Bitcoin alphabet without 0, O, I, l | None | Yes | Short identifiers such as crypto addresses |
| Hexadecimal | 0–9, a–f (or A–F) | None | Yes | Exact byte dumps, debugging, low-level protocols |
Base100 is the only format in the comparison whose alphabet lives entirely outside ASCII, so it is also the only one that depends on a destination that can carry supplementary plane symbols without modification. That makes it visually distinctive in emoji-rich contexts but fragile in plain-text channels, where Base64 or hexadecimal will travel more reliably.
Where Base100 Fits — and Where It Breaks Down
Base100 is a reversible byte encoding, not a security tool. It does not hide information, it does not sign information, and it does not detect tampering, because there is no checksum and the mapping is public. Anyone who knows that byte b becomes U+1F3F7 + b can recover the original bytes instantly, so a base100 decoder is also a base100 encoder in disguise. If you need to protect a password, an API token, a private key, or any confidential message, use reviewed encryption with an authenticated mode such as AES-GCM and a key derivation function — not Base100.
The same absence of integrity checks means a single substituted symbol silently corrupts one byte. Because Base100 has no length marker, padding, or checksum, a decoder cannot tell whether a valid-looking change was accidental or malicious, and the recovered bytes may still parse as valid UTF-8 even when they no longer match the sender's intent. Treat any Base100 stream that crossed an untrusted boundary as suspect and verify the recovered text against a separate channel before acting on it.
There are also practical limits to keep in mind. The browser-side tool restricts either direction to 500,000 bytes or symbols so that an accidental huge paste does not freeze the page. Empty input is rejected, the output is never silently truncated, and the decoder uses fatal UTF-8 validation rather than inserting replacement characters when the recovered bytes are not valid UTF-8. Together these rules make Base100 a useful, well-bounded way to move UTF-8 text through emoji-friendly channels, as long as you respect what it is and what it is not.