Base100 maps each UTF-8 byte to exactly one Unicode code point in the inclusive range U+1F3F7 through U+1F4F6, using the formula U+1F3F7 plus the byte value. That single rule — byte zero becomes U+1F3F7 and byte 255 becomes U+1F4F6 — is the entire encoding. Because the mapping is one-to-one, every byte of the source string turns into one symbol and the stream decodes by reversing the same math: subtract U+1F3F7 from each code point to recover the original byte, then validate the resulting byte sequence as strict UTF-8. There is no padding, delimiter, checksum, length marker, compression, semantic translation, or human-language interpretation layered on top. The encoder first converts the input string to UTF-8, so plain ASCII text yields exactly one Base100 symbol per character, while non-ASCII text expands in proportion to its UTF-8 byte count — accented letters, CJK ideographs, and emoji in the input each contribute as many symbols as their UTF-8 representation requires. A cheat sheet for the format therefore only needs the formula, the inclusive byte range, and a short list of pitfalls that break strict decoding in chat apps, editors, and emoji-rendering pipelines. Use the Base100 Encoder / Decoder as a one-page reference for both directions.
The Base100 Mapping at a Glance
Base100 encoding has a single rule that fits on one line: the byte value is added to U+1F3F7 to produce the output code point. Every byte from 0 to 255 maps to a distinct symbol in the inclusive range U+1F3F7 to U+1F4F6. There is no padding, no delimiter, no checksum, and no length marker — the stream is just one mapped symbol after another. Because the math is fixed and reversible, a conformant encoder and decoder must agree on every code point, regardless of the fonts, platforms, or rendering engines involved. Independent fixtures in the original implementation lock the lower and upper code points, so any conformant implementation must agree on them. The format itself was introduced by Adam Niederer's Base100 project, and the byte formula is the equivalent form documented in independent Go implementations.
The mapping operates on bytes, not on user-perceived characters. The encoder first converts the input string to UTF-8, then maps each resulting byte. ASCII text produces one Base100 symbol per source character. Non-ASCII text usually produces more symbols because a single Unicode character can require several UTF-8 bytes. For a deeper walk through the byte-to-symbol math, the Base100 Encode: Map UTF-8 Bytes to Emoji Symbols guide expands on the same byte formula with a few worked offsets.
| Byte value | Resulting code point | Meaning |
|---|---|---|
| 0 | U+1F3F7 | Lower bound of the Base100 range |
| 1 | U+1F3F8 | One byte above the lower bound |
| 128 (0x80) | U+1F477 | Midpoint byte in the 0–255 range |
| 255 | U+1F4F6 | Upper bound of the Base100 range |
These anchor points are the easiest values to verify by eye when you want to confirm a stream is well-formed. The original Rust project is the format source, and the WHATWG Encoding Standard defines the browser UTF-8 behavior used at the text boundary.
Encode UTF-8 Text in Three Steps
- Choose Text to Base100. Make sure the mode is set to encode, not decode. The Base100 Encoder / Decoder exposes both directions through separate controls, so picking the wrong mode silently produces nonsense on the clipboard.
- Enter or paste the source text. The encoder converts the string to UTF-8 first, so Unicode characters such as accented letters, CJK ideographs, or emoji are accepted as long as they round-trip through UTF-8 cleanly. Empty input is rejected rather than silently producing a zero-symbol stream.
- Run the encoder and copy the symbol stream. The output is exactly one Base100 symbol per UTF-8 byte. Copy it through a channel that preserves code points: a plain-text buffer, a code block, or a file. Do not paste the stream through editors or chat apps that may insert spaces, line breaks, or variation selectors between the symbols.
For ASCII text the output length matches the input length because one ASCII character is one UTF-8 byte. For non-ASCII text the output grows in proportion to the UTF-8 byte count, so a single emoji in the input can produce three or four Base100 symbols. The symbol count therefore measures encoded bytes, not characters, words, or grapheme clusters. The original JavaScript string length is never the right metric for the output size.
Decode Base100 Symbols Back to Text
- Choose Base100 to text. Switch the mode so the operation runs in reverse. Decoding uses the same math in reverse: the byte value is recovered by subtracting U+1F3F7 from each code point.
- Paste the unmodified symbol stream. Every code point must lie inside the inclusive range U+1F3F7 through U+1F4F6. Spaces, line breaks, punctuation, variation selectors, and emoji outside that range are explicitly rejected. The decoder reads by Unicode code point rather than UTF-16 code unit, so supplementary-plane symbols are not split.
- Run the decoder. The collected bytes are passed through a fatal UTF-8 validator. If the bytes do not form a valid UTF-8 sequence, the tool reports an error instead of silently inserting replacement characters. A successful round trip is therefore evidence that the stream is well-formed and unchanged.
Strict validation is the reason Base100 is reliable for transport: any accidental edit, dropped code point, or inserted whitespace breaks decoding in a way you can see, rather than producing a wrong-but-plausible string.
Why a Visually Similar Paste Fails
Base100 streams are unusually fragile in chat and word-processor environments because the mapped code points sit inside a dense block of emoji that apps love to decorate. A symbol that looks correct on screen may carry a hidden variation selector, may have been substituted by a different emoji, or may have been split by a smart auto-formatter. The decoder rejects every one of those changes because none of them is part of the original Base100 syntax.
The most common failure modes are:
- Inserted variation selector U+FE0F. Many emoji keyboards add this selector to make symbols render in color. The mapped code point is still present, but the extra selector makes the stream bytewise invalid for strict decoding.
- Inserted zero-width joiners or spaces. Some editors normalize runs by inserting invisible characters. Decoding rejects any character outside the 256-symbol window.
- Auto-substitution by an emoji picker. A picker may replace a less common code point with a more familiar one. The substitution is visually similar but mathematically different.
- Line wraps or paragraph breaks. A long stream that wraps in a chat window is no longer a single uninterrupted run of code points.
Preserve the exact code points when interoperability matters. If you must move a stream through an unreliable channel, the safest path is to keep it inside a code block or a plain-text file that is not auto-formatted.
Limits, Size, and Processing Location
The Base100 Encoder / Decoder caps each direction at 500,000 bytes or symbols so an accidental huge paste cannot freeze the browser. Inputs that exceed the cap are rejected at the boundary rather than truncated silently. Empty input is rejected for the same reason: a zero-length stream cannot be a valid Base100 payload. The byte and symbol limits refer to the same number because the mapping is one-to-one, but the tool tracks them separately so encode and decode enforce the same ceiling in their own units.
All encoding and decoding happen in the browser. The input string is not uploaded, and the output is produced by client-side JavaScript against the WHATWG Encoding Standard's UTF-8 algorithm at the text boundary. That makes the tool usable for moderately sensitive strings, but it does not make Base100 a confidentiality mechanism. The mapping is public and reversible: anyone who sees the stream can recover the bytes, and there is no checksum to detect a tampered but syntactically valid stream.
Base100 Is Not Encryption, Compression, or Steganography
Base100 is an encoding. The four properties people often confuse it with are explicitly absent:
- Encryption. Base100 provides no secrecy. The formula U+1F3F7 + byte is public, so anyone with the stream and the rule can recover the bytes. Do not use it for passwords, tokens, or private messages.
- Hashing or signing. There is no checksum, MAC, or signature. A stream that decodes successfully tells you nothing about whether it was modified along the way.
- Compression. Because the mapping is exactly one symbol per byte, the output is never shorter than the input. Non-ASCII text expands because one Unicode character often requires multiple UTF-8 bytes.
- Steganography or human-language translation. The symbols are not chosen for any visual meaning. Byte 65 is whatever code point U+1F3F7 + 65 resolves to whether the source character looks like that symbol or not. Emoji rendering varies across operating systems and fonts, so the visual picture is not part of the format.
If you need secrecy or tamper detection, use reviewed encryption such as AES-GCM with a real key and authenticate the ciphertext. If you need a smaller ASCII-friendly payload, Base64 Encode / Decode or hexadecimal are usually more portable choices because Base100 streams depend on emoji-range code points surviving transport unchanged.