Is Base100 a form of encryption?

No. Base100 is a reversible byte encoding. Anyone who knows the mapping can decode it, and it provides no secrecy or authentication.

Why can one character become several emoji symbols?

Base100 maps UTF-8 bytes, not characters. Non-ASCII characters often use multiple UTF-8 bytes, and each byte becomes one symbol.

Why does a visually similar pasted value fail to decode?

Another app may have inserted a variation selector, space, line break, or substituted code point. Strict Base100 accepts only code points from U+1F3F7 through U+1F4F6 and rejects everything else.

What is the exact byte-to-symbol formula used in the example?

code_point = U+1F3F7 + byte, where U+1F3F7 is decimal 127991 and the byte ranges from 0 to 255. The result is the hex code point, such as U+1F43F for byte 72.

Base100 Encode Example: A Worked Walkthrough

Base100 encodes a UTF-8 string by turning every byte into one Unicode code point from U+1F3F7 through U+1F4F6, using the formula code_point = U+1F3F7 + byte_value, where byte_value runs from 0 to 255. Byte 0 maps to U+1F3F7, byte 1 maps to U+1F3F8, and byte 255 maps to U+1F4F6. The conversion runs in the Base100 Encoder / Decoder, which first turns the input text into its UTF-8 byte sequence and then produces exactly one symbol per byte. A small ASCII example makes the rule concrete: the letter "A" is byte 65, so 65 plus U+1F3F7 (decimal 127991) gives U+1F438 — a single symbol that represents one byte of the original input. Because the mapping is strictly 1 byte to 1 code point over the inclusive 256-code-point range, every Base100 encode example has the same shape: a numeric offset added to a fixed start code point, applied independently to each byte. The result is a stream of emoji-range symbols with no separators, padding, length markers, or checksums.

How the byte-to-symbol mapping is defined

Base100 was introduced by Adam Niederer as a teaching example of how a single byte can be hidden inside the supplementary multilingual plane. The original Rust implementation ships with this exact byte-to-code-point formula, and an independent Go library documents the same byte arithmetic, which is what keeps the format stable across tools. The mapping itself is fixed and public, and that is the reason the encoding is reversible: anyone with the table can recover the original bytes. Three official boundaries anchor the format:

Byte value	Code point	Role
0	U+1F3F7	First symbol in the range
1	U+1F3F8	Second symbol in the range
128	U+1F477	Midpoint of the range
255	U+1F4F6	Last symbol in the range

Because the byte value is added directly to U+1F3F7, the resulting code points form a contiguous block of 256 values inside the supplementary multilingual plane. The encoder produces one symbol per byte, with no padding, delimiter, checksum, compression, length marker, or semantic translation between symbols. No code points outside U+1F3F7..U+1F4F6 are valid Base100 symbols, and the encoder does not invent any. Once you know the input's UTF-8 bytes, the same table is enough to predict any Base100 encode example by hand.

A worked example: encoding "Hi!" byte by byte

A small, fully traceable example shows every step of the formula without needing external tooling. Use the input string "Hi!" and walk through it as follows.

Formula: code point = U+1F3F7 + byte Numeric anchor: U+1F3F7 = decimal 127991

Step 1 — Convert the input to UTF-8 bytes. ASCII characters fit in one byte each, so the three characters give three bytes:

"H" → byte 72 (0x48)
"i" → byte 105 (0x69)
"!" → byte 33 (0x21)

Step 2 — Apply the offset to each byte. Adding 127991 to each decimal byte and converting back to hex gives the Base100 code points:

127991 + 72 = 128063 → U+1F43F
127991 + 105 = 128096 → U+1F460
127991 + 33 = 128024 → U+1F418

Step 3 — Concatenate the symbols in order. The output stream is U+1F43F, then U+1F460, then U+1F418, with no separator between them. The input produced three bytes and the encoder returned three symbols. This 1:1 relationship is the same shape that every Base100 encode example takes for plain ASCII text, because the original ASCII encoding is already one byte per character.

Encoding a Base100 example step by step

The fastest way to verify the worked example above is to reproduce it through the browser tool. The same screen reverses the encoding for decoding.

Open the Base100 Encoder / Decoder and pick the "Text to Base100" mode.
Type or paste the UTF-8 text you want to encode, such as a short message, a code snippet, or the "Hi!" string from the worked example.
Run the encoder so each byte in the UTF-8 representation maps to one code point between U+1F3F7 and U+1F4F6.
Copy the symbol stream exactly as it appears, with no added spaces, line breaks, punctuation, or variation selectors.
To reverse the operation, switch to "Base100 to text", paste the unmodified symbol stream, and run the decoder.
If any symbol falls outside the 256-code-point range, or the resulting bytes are not a valid UTF-8 sequence, the decoder rejects the input instead of producing a partially correct result.

Why the symbol count is not the character count

A reader who only looks at the input text often expects one Base100 symbol per typed character. That expectation only holds for plain ASCII text, because every ASCII character fits in a single UTF-8 byte. As soon as the input contains non-ASCII characters, the byte count rises and so does the symbol count. To make the rule concrete, walk through the four-character word "café":

"c" → byte 99 (0x63)
"a" → byte 97 (0x61)
"f" → byte 102 (0x66)
"é" (Unicode U+00E9) → UTF-8 bytes 195 (0xC3) and 169 (0xA9)

Four typed characters therefore become five UTF-8 bytes, and the Base100 encoder returns five symbols for this input. The same expansion happens with accented letters, CJK characters, and emoji in the source text, because each Unicode code point outside ASCII uses two to four UTF-8 bytes. The encoder therefore measures encoded bytes, not user-perceived characters, grapheme clusters, words, or original JavaScript string length. This is a frequent source of confusion when comparing the length of the source string to the length of the encoded output, and it is one of the clearest side effects visible in any Base100 encode example.

Limits, errors, and the strict decoder

Three constraints from the implementation directly shape every Base100 encode example you can produce, and they explain why some pasted values fail to round-trip.

Range

The decoder only accepts code points from U+1F3F7 through U+1F4F6. Anything else — spaces, line breaks, variation selectors, punctuation, or substituted glyphs — is rejected, because none of those characters are part of the original format. The decoder intentionally treats them as framing errors, not as ignorable noise.

UTF-8 validity

After the byte values are recovered by subtracting U+1F3F7 from each code point, the decoder runs a fatal UTF-8 validation. If the byte sequence is not a well-formed UTF-8 string, the tool reports an error rather than silently inserting replacement characters and pretending the result is exact. The WHATWG Encoding Standard defines the UTF-8 behavior used at the text boundary.

Size

The page caps either direction at 500,000 bytes or symbols, so accidental huge pastes do not freeze the browser. Empty input is rejected, and output is never silently truncated. Independent fixtures lock the lower and upper code points plus representative byte offsets, which is how the implementation guarantees the boundary values from the table above.

Emoji rendering varies across operating systems, fonts, browsers, and messaging platforms. Some mapped code points appear as colorful images, others as monochrome glyphs, boxes, or unexpected pictographs. Rendering does not alter the mathematical mapping inside a conforming string, but copying through a system that substitutes, strips, or decorates characters can. A pasted value that looks identical to the original on screen may still contain a variation selector such as U+FE0F, a soft hyphen, or a normalization change that strict decoding rejects. Preserve the exact code points when interoperability matters, because there is no checksum to detect an accidental change.

When another encoding fits better

Base100 is one of many text encodings available on this site. The table below compares use cases qualitatively; the exact output sizes depend on the input, and the chosen tool will give you the precise numbers for your data.

Need	Better fit on this site	Reason
ASCII-only transport through systems that strip emoji	Base64, Base32, Base58, or hexadecimal encoders	Wide compatibility across transports, files, and APIs
Reversible visual demo with emoji-style output	Base100 Encoder / Decoder	One symbol per byte in the exact U+1F3F7..U+1F4F6 range
Secrecy, password protection, or tamper detection	AES, HMAC, RSA, or SHA tools	Reviewed cryptography with authentication, not a visible mapping
Hex bytes, binary bytes, or numeric code points	Hex, binary, or Unicode code-point converters	Inspect the raw byte or scalar value of the input

Base100 is an encoding, not encryption, hashing, signing, authentication, compression, steganography, or human-language emoji translation. Anyone with the mapping can recover the text, and a changed symbol changes a byte without any built-in checksum to flag the change. For passwords, tokens, private keys, or confidential messages, use reviewed encryption and authenticated formats instead. For a quick reference table of bytes, emojis, and decoding patterns that complement this worked example, see the Base100 encode cheat sheet.