Base100 encoding maps each UTF-8 byte to one Unicode code point in the inclusive range U+1F3F7 through U+1F4F6 using the single formula code point = U+1F3F7 + byte value, so byte 0 becomes U+1F3F7, byte 1 becomes U+1F3F8, and byte 255 becomes U+1F4F6. To encode a string, the implementation first converts it to UTF-8, then turns every resulting byte into one of the 256 reserved emoji-range code points; to decode, it walks the input one code point at a time, subtracts U+1F3F7 to recover each byte, and runs the byte sequence through a strict UTF-8 validator. The output is a visible stream of emoji-like symbols, one per input byte, with no padding, delimiters, length marker, or checksum. Because the mapping is purely arithmetic and fully reversible by anyone who knows the offset, Base100 is treated as a byte encoding rather than a security tool. Every part of that contract is implemented locally by the Base100 Encoder / Decoder, which encodes and decodes entirely in the browser without uploading the input.
How the Byte-to-Code-Point Formula Works
The mapping introduced by Adam Niederer's Base100 project is the entire specification: take one byte, add U+1F3F7, and you have the symbol. Three concrete byte values anchor the formula at both ends and in the middle:
- Byte 0 → U+1F3F7
- Byte 1 → U+1F3F8
- Byte 255 → U+1F4F6
For a printable ASCII character such as the letter "A", the input byte is 65. Substituting into code point = U+1F3F7 + 65 gives 0x1F3F7 + 0x41 = 0x1F438, which is the rendered Base100 symbol for "A". Because every byte maps to exactly one symbol, the symbol count of a Base100 stream equals the UTF-8 byte count of the source text, never the user-perceived character count. There is no chunking, no compression, and no semantic translation — emoji names, meanings, and visual categories carry no information, they are simply the side effect of using a code-point range that most fonts render with emoji glyphs.
An independent Go implementation, the Dongle Base100 documentation, records the same byte formula, and any conforming decoder only needs the offset U+1F3F7 to recover the bytes. The WHATWG Encoding Standard defines the UTF-8 behavior used at the boundary between JavaScript strings and bytes, which is why a strict decoder can reject malformed UTF-8 instead of silently replacing it with the U+FFFD replacement character.
Why Base100 Always Goes Through UTF-8 First
Base100 does not operate on JavaScript characters, grapheme clusters, or words; it operates on bytes. JavaScript strings are sequences of UTF-16 code units, and characters outside the Basic Multilingual Plane use surrogate pairs, so treating "characters" as the atomic unit would lose information. To avoid that, the encoder always converts the input string to UTF-8 first, producing a byte sequence where every character uses exactly the byte count required by the UTF-8 standard. Ordinary ASCII text produces one Base100 symbol per character because each ASCII character is a single UTF-8 byte. Non-ASCII text usually expands: accented Latin letters become two bytes, CJK characters become three bytes, and supplementary-plane characters such as most emoji become four bytes. A single user-perceived character can therefore produce two, three, or four Base100 symbols.
This expansion is why a Base100 output stream is measured in bytes rather than characters, and why a short user string can yield a noticeably longer symbol stream. For example, the single-character string "é" is one UTF-16 code unit but two UTF-8 bytes (0xC3 0xA9), so its Base100 output contains two symbols, not one. Users who paste CJK text, emoji, or accented letters should expect the symbol count to grow roughly in proportion to the UTF-8 size of the input, and they should not try to count "characters" in the output to estimate the original length.
How to Use the Base100 Encoder / Decoder
The Base100 Encoder / Decoder exposes two operations on a single page, both of which run locally in the browser. The steps below cover both directions.
- Open the Base100 Encoder / Decoder page.
- Choose Text to Base100 for encoding or Base100 to text for decoding.
- For encoding: type or paste UTF-8 text into the input field. The tool converts the string to UTF-8, then maps every byte to one code point from U+1F3F7 through U+1F4F6.
- Run the conversion. The output appears as a single contiguous stream of emoji-range symbols with no added spaces, line breaks, or variation selectors.
- Copy the output exactly as produced. Do not introduce whitespace, punctuation, or emoji decoration between symbols — those characters are not framing syntax in the original format.
- For decoding: switch to Base100 to text and paste the unmodified symbol stream into the input field.
- Run the decoder. Every symbol must fall inside U+1F3F7 through U+1F4F6; spaces, line breaks, variation selectors, and emoji outside the range are rejected.
- If the bytes form valid UTF-8, the original text appears. If they do not, the tool reports an error rather than pretending the result is exact.
The page enforces a limit of 500,000 bytes or symbols in either direction so accidental huge pastes do not freeze the browser. Empty input is rejected, output is never silently truncated, and decoding uses fatal UTF-8 validation. If you prefer a step-by-step worked example rather than the live tool, see the Base100 Encode worked walkthrough.
What the Decoder Rejects and Why
Strict Base100 decoding is unforgiving on purpose. The decoder reads the input by Unicode code point rather than by UTF-16 code unit, which means it counts symbols the way the original format does. Every symbol must fall inside the inclusive range U+1F3F7 through U+1F4F6, and any character outside that window — including spaces, line breaks, punctuation, variation selectors, and emoji that happen to be one code point away — causes the decode to fail. The byte value is then recovered by subtracting U+1F3F7, and the resulting byte sequence is fed into a strict UTF-8 decoder. If the bytes do not form a valid UTF-8 sequence, the tool reports an error instead of silently inserting replacement characters and presenting a lossy result as exact.
This strictness matters in practice because chat apps, editors, keyboards, and normalization pipelines often insert invisible characters. A stream that looks identical on screen can therefore be bytewise different and fail strict decoding. Common culprits include the variation selector U+FE0F, which some platforms append to emoji-shaped characters, and normalization forms that decompose or recompose code points. Preserve the exact code points when interoperability matters, and if a paste suddenly fails to decode, treat invisible decoration as the most likely cause. Independent fixtures lock the lower and upper code points plus representative byte offsets so the mapping behaves the same way every time.
Comparing Base100 to Other Byte Encodings
Base100 is one option among several reversible byte encodings, and the right choice depends on what the destination expects. The table below compares Base100, Base64, Base32, and hexadecimal on the criteria that usually drive the decision.
| Encoding | Output alphabet | Symbols per byte | ASCII-safe transport | Typical use |
|---|---|---|---|---|
| Base100 | U+1F3F7 through U+1F4F6 (emoji range) | 1 byte per symbol | No (multi-byte UTF-8 per symbol) | Visual, playful, byte-faithful streams |
| Base64 | A–Z, a–z, 0–9, +, /, = | ~1.33 symbols per byte | Yes | Email, JSON, data URIs, tokens |
| Base32 (RFC 4648) | A–Z, 2–7, = | ~1.6 symbols per byte | Yes | Case-insensitive, human-typed codes |
| Hexadecimal | 0–9, a–f (or A–F) | 2 symbols per byte | Yes | Debug dumps, checksums, byte-level inspection |
If the destination requires ASCII-only transport, Base64, Base32, or hexadecimal is usually more compatible; Base100's emoji-range output uses multi-byte UTF-8 sequences and may be substituted or decorated by intermediate systems. If the goal is a visually distinctive, byte-for-byte faithful stream and the destination preserves emoji code points, Base100 is appropriate.
Security and Limitations You Should Know
Base100 is an encoding, not encryption, hashing, signing, authentication, compression, or steganography, and it provides no secrecy or integrity guarantees. Anyone who knows the offset U+1F3F7 can recover every byte of the input, and a syntactically valid but tampered symbol changes exactly one byte without any built-in checksum to flag the difference. Treat Base100 the same way you would treat plain text: useful for moving bytes through a system that preserves the emoji range, unsuitable for protecting passwords, personal data, private keys, tokens, or confidential messages. For secrecy and tamper detection, use reviewed encryption and authenticated formats.
Emoji rendering varies across operating systems, fonts, browsers, and messaging platforms, so the same code point can appear as a colorful image, a monochrome glyph, a tofu box, or an unexpected pictograph. Rendering never alters the mathematical mapping inside a conforming string, but copying through a system that substitutes, strips, or decorates characters can change the underlying code points and break strict decoding. The decoder intentionally rejects those transformations rather than guess. For a wider checklist of edge cases and recovery tactics, the Base100 cheat sheet collects common failure modes in one place.