Base100 encoding maps each UTF-8 byte to exactly one Unicode code point by adding the byte value to U+1F3F7, producing a symbol stream that runs from U+1F3F7 (byte 0) through U+1F4F6 (byte 255). The conversion happens at the byte level: the encoder first turns your text into UTF-8, then walks the byte stream and replaces each byte with a single code point in the Supplementary Multilingual Plane. A 7-bit ASCII character becomes one Base100 symbol, and the resulting string is visually distinctive because every code point lives in an emoji block. There is no padding, no delimiter, no checksum, and no compression, which keeps the output length predictable at one symbol per input byte. Non-ASCII text expands because one Unicode character can require several UTF-8 bytes, so accented letters, CJK glyphs, and emoji in the original input each produce more than one Base100 symbol. The output length therefore measures encoded bytes, not user-perceived characters, grapheme clusters, or words. Anyone who knows the offset can reverse the mapping, which makes Base100 a reversible byte encoding rather than a secret-keeping scheme. A Base100 Encoder / Decoder handles the UTF-8 conversion, the byte-to-code-point mapping, and the strict reverse validation locally in your browser, so the input never leaves the device.
How the Base100 Byte-to-Symbol Mapping Works
The original Base100 project defines a one-to-one relationship between every byte from 0 to 255 and a specific emoji-range Unicode code point. The offset is U+1F3F7, so byte 0 becomes U+1F3F7, byte 1 becomes U+1F3F8, and byte 255 becomes U+1F4F6. The intermediate bytes fill the rest of the range without gaps. Because the alphabet is exactly 256 code points, every possible UTF-8 byte has a defined destination and every destination decodes back to exactly one byte.
The mapping is purely mathematical. The visible emoji glyph that each code point renders as depends on the platform, font, browser, or chat application. Some render as colorful pictures, some as monochrome outlines, and some as missing-glyph boxes. None of that changes the underlying code points inside a conforming string, but copying through a system that substitutes, strips, or decorates characters can change the bytes and break strict decoding.
| Byte value | Decimal | Hex | Code point |
|---|---|---|---|
| Lowest mapped byte | 0 | 0x00 | U+1F3F7 |
| Second byte | 1 | 0x01 | U+1F3F8 |
| ASCII 'A' | 65 | 0x41 | U+1F438 |
| ASCII DEL | 127 | 0x7F | U+1F476 |
| First UTF-8 continuation byte | 128 | 0x80 | U+1F477 |
| Highest mapped byte | 255 | 0xFF | U+1F4F6 |
The boundary values matter because they define what a strict decoder accepts and what it rejects. Anything outside U+1F3F7 through U+1F4F6 fails validation, including common variation selectors such as U+FE0F, leading spaces, line breaks, punctuation, and emoji that look similar but live in a different block.
How to Encode Text into Base100 Symbols
The encoding direction maps bytes to symbols. Open the Base100 Encoder / Decoder, choose the Text to Base100 mode, and follow these steps:
- Type or paste UTF-8 text into the input field. The tool accepts any Unicode character the browser can represent, including accents, CJK characters, and emoji inside the original input.
- Run the encoder to convert the string to UTF-8 bytes and map each byte to one Base100 code point by adding its value to U+1F3F7.
- Read the resulting symbol stream. The output length equals the UTF-8 byte count of your input, which is usually one symbol per ASCII character and several symbols per non-ASCII character.
- Copy the exact symbol stream to the clipboard without inserting spaces, line breaks, or variation selectors.
- If you need to send the stream through another app, paste it as plain text and avoid rich-text editors that may decorate the emoji.
Worked example for a single ASCII byte. Take the character 'A'. In UTF-8 it is one byte with decimal value 65. The Base100 formula is code point = U+1F3F7 + byte. Substituting the values: code point = U+1F3F7 + 65 = U+1F438. The encoder therefore replaces 'A' with the single code point U+1F438. A short ASCII string of N characters produces N symbols, while a three-byte UTF-8 character such as the euro sign '€' produces three symbols. The total symbol count you see is the encoded byte count, not the original JavaScript string length.
How to Decode Base100 Back to UTF-8 Text
The decoding direction reverses the mapping. Use the same tool but choose the Base100 to text mode:
- Paste a valid, unmodified symbol stream into the input field. Every code point must fall inside U+1F3F7 through U+1F4F6 inclusive.
- Run the decoder to walk the input by Unicode code point, subtract U+1F3F7 from each symbol to recover its byte value, and collect the bytes into a stream.
- The decoder passes the byte stream through a strict UTF-8 validator. If the bytes form valid UTF-8, the tool returns the original text.
- If the bytes are not valid UTF-8, the tool reports an error instead of inserting replacement characters or pretending the round-trip succeeded.
- Read the result. Empty input is rejected, partial input is rejected, and any stray spaces, line breaks, or variation selectors cause the entire stream to fail strict validation.
Reading the input by Unicode code point rather than by UTF-16 code unit matters because every Base100 code point lives in the Supplementary Multilingual Plane. A naive JavaScript decoder that iterates over UTF-16 code units would split supplementary code points in half and produce junk bytes. The tool guards against that by validating the range before it subtracts the offset.
Why Base100 Is Not Encryption or a Hash
Base100 is an encoding, not a cipher, not a hash, not a signature, and not a steganography scheme. The mapping table is public: subtract U+1F3F7 from any code point in the valid range and you have the original byte. Anyone with the offset can decode a Base100 stream with a one-line script, so Base100 provides no secrecy and no authentication.
There is also no checksum, length marker, or tamper detector. A changed symbol changes a byte, but the decoder cannot tell whether the change was intentional or accidental. The browser-based validator will only flag structurally invalid streams, such as a stray space or an out-of-range code point, not semantically altered ones.
For ASCII-safe transport and for confidentiality, prefer reviewed alternatives. Hex encoding produces only 0 through 9 and a through f, which survives every text channel. Text to Hex: Encode UTF-8 Strings the Right Way walks through the same UTF-8 boundary with a different alphabet. For confidentiality, use an authenticated encryption format such as AES-GCM with a key you control, or a standard password manager. Do not use Base100 to protect passwords, tokens, private keys, or confidential messages.
Common Reasons a Base100 Stream Fails to Decode
Most decode failures come from the transport, not the encoding. Some chat apps, keyboards, or normalization pipelines insert a variation selector such as U+FE0F after an emoji to force a colorful presentation. That selector is not part of the Base100 alphabet, so the strict decoder rejects the stream. Editors that auto-format text can insert non-breaking spaces, zero-width joiners, or zero-width spaces that look invisible but add bytes. Some platforms substitute an emoji with a visually similar one from a different block, which shifts the code point out of the U+1F3F7 to U+1F4F6 range.
A stream that looks similar on screen can therefore be bytewise different from the encoder output. When interoperability matters, copy the stream as plain text, paste it into a hex viewer or a code-point inspector to confirm each symbol is in range, and avoid rich-text editors between the encoder and the decoder. The same UTF-8 boundary that lets the encoder support any Unicode character is the place where transport apps most often break the round-trip.
Base100 vs. Other Byte Encodings
Base100 sits in a family of byte-to-text encodings that differ in alphabet size, transport safety, and output expansion. Hex, Base32, Base58, and Base64 are all designed to survive ASCII-only channels; Base100 is designed for visual distinctiveness at the cost of transport safety.
| Encoding | Alphabet size | Symbol type | Output expansion (ASCII input) | Notes |
|---|---|---|---|---|
| Base100 | 256 | Emoji-range code points | 1 byte to 1 symbol | Visually distinctive, not ASCII-safe |
| Hex | 16 | 0-9, a-f | 1 byte to 2 chars | ASCII-safe, easy to read |
| Base32 | 32 | A-Z, 2-7 | 5 bytes to 8 chars | ASCII-safe, case-insensitive |
| Base58 | 58 | Alphanumeric minus look-alikes | ~1.37 chars per byte | Common for crypto addresses |
| Base64 | 64 | A-Z, a-z, 0-9, +, / | 3 bytes to 4 chars | Widely supported, ASCII-safe |
The trade-off comes from the alphabet size. Base100 reaches a perfect 1:1 expansion at the cost of moving every symbol out of the ASCII range. Hex, Base32, Base58, and Base64 stay inside ASCII and pay for that compatibility with longer output. If the destination accepts emoji-range Unicode, Base100 gives the most compact and most recognizable stream. If the destination requires ASCII-only transport, switch to Base64, Base58, Base32, or hex.
The tool limits either direction to 500,000 bytes or symbols so an accidental huge paste does not freeze the browser. Empty input is rejected, output is never silently truncated, and decoding uses fatal UTF-8 validation. All processing happens locally: the encoder, the byte-to-code-point mapper, and the strict decoder run inside the page, with no upload of your text or symbols.