Base100 is a byte-to-emoji mapping where each byte b is replaced by a character containing the code point U+1F3F7 plus b, so byte 255 becomes U+1F4F6 and byte 0 becomes U+1F3F7. A working Base100 encoder / decoder alternative has to honor that exact formula: convert the input string to UTF-8 first, add the byte value to U+1F3F7 for encoding, subtract it for decoding, and reject any pasted value that contains code points outside the 256-symbol block. The mapping was introduced by Adam Niederer's Base100 project, and several command-line forks, Go libraries, and web tools have followed it. Switching between them is straightforward in principle, but real-world alternatives differ in how they handle UTF-8 validation, byte limits, clipboard transformations, and whether they run locally or require a server round trip. The Base100 Encoder / Decoder runs entirely in the browser, refuses silently invalid input, and applies fatal UTF-8 decoding so a pasted stream that no longer matches the original bytes fails loudly with an error rather than producing a corrupted string.
The keyword phrase "base100 encoder / decoder alternative" usually means a reader who already knows the format and wants to replace one implementation with another that better fits a specific constraint. That constraint is often privacy (no upload to a remote server), strict correctness (no replacement characters on bad input), or convenience (no Rust toolchain to install). The sections below describe what to compare before switching, how to use the Lizely tool as a replacement, and the specific pitfalls that make a visually identical pasted stream fail strict decoding.
Why readers look for a Base100 encoder / decoder alternative
The original Base100 was written by Adam Niederer as a Rust command-line tool that maps every byte of an input stream to a unique character in a 256-symbol emoji block. It is the canonical reference implementation, and any tool that claims to be a compatible Base100 encoder / decoder alternative has to follow the same byte-to-symbol rule. Readers tend to search for an alternative when one of three things happens with the existing setup.
- Local installation is impractical. The original Rust crate and several Go ports must be compiled or installed before use. A reader working from a managed laptop, a phone, or a borrowed machine often wants a tool that opens in a browser tab instead.
- Privacy rules block uploads. Older web-based Base100 converters paste the text into a backend that returns the encoded stream. For confidential inputs that approach is unacceptable, so a client-side alternative is preferred.
- Silent UTF-8 errors break round-trips. Some implementations replace invalid bytes with the Unicode replacement character (U+FFFD) and report success. That masks a real failure and the decoded text no longer matches the original byte stream.
Each of those pain points points at the same architectural choice: the alternative must convert locally, validate strictly, and never silently rewrite bytes. The Lizely tool does all three.
What makes this Base100 alternative different
Several documented properties separate a conformant alternative from a sloppy clone. They are all visible in the Lizely implementation and all match the rules in the original Base100 README and the Go reference library.
- Strict byte range enforcement. The decoder accepts only code points from U+1F3F7 through U+1F4F6. Spaces, line breaks, punctuation, variation selectors, and emoji outside that block are rejected outright.
- Fatal UTF-8 validation. After the symbols are converted back to bytes, the bytes are decoded as UTF-8 using the WHATWG Encoding Standard. If the byte sequence is not valid UTF-8, the tool returns a clear error instead of inserting replacement characters.
- Local processing only. Encoding and decoding happen in the browser. The text never leaves the device, which removes a category of compliance risk for confidential inputs.
- Fixed byte limit. Either direction is capped at 500,000 bytes or symbols so that an accidental huge paste does not freeze the tab.
- No padding, checksum, or delimiter. The mapping is one symbol per byte. There is no length marker, no separator, and no hash to detect tampering, so any change to a single symbol changes the corresponding byte.
How to encode text with the Base100 alternative
- Open the Base100 Encoder / Decoder and choose Text to Base100.
- Type or paste the UTF-8 text you want to encode. The tool first converts the string to UTF-8 bytes, so accented letters, CJK characters, and emoji each expand according to their UTF-8 representation.
- Run the encoder. Each byte b becomes the code point U+1F3F7 + b, and the tool produces one Base100 symbol per byte.
- Copy the resulting symbol stream. Do not add spaces, line breaks, or variation selectors, because the decoder rejects any character that is not inside the 256-symbol range.
- Paste the stream into the destination that needs the encoded form. If the destination renders the symbols as colorful emoji, monochrome glyphs, or boxes, the rendering does not change the underlying code points, so the stream remains decodable as long as the code points were not substituted.
For ordinary ASCII text the symbol count equals the character count. For non-ASCII text the symbol count is usually higher because one user-perceived character often uses several UTF-8 bytes. The output therefore measures encoded bytes, not characters, words, or grapheme clusters.
How to decode symbols back to text
Decoding reverses the same formula. Switch the tool to Base100 to text, paste the unmodified symbol stream, and run the decoder. Every symbol must land inside U+1F3F7 through U+1F4F6 inclusive. The tool subtracts U+1F3F7 from each code point to recover the byte value, collects all the bytes, and then runs the WHATWG UTF-8 decoder to rebuild the original text.
If the stream is invalid, three distinct failure modes can occur:
- Out-of-range code point. A symbol outside U+1F3F7 through U+1F4F6 is rejected immediately, because the formula cannot recover a valid byte from it.
- Variation selector or hidden character. Some chat apps, editors, keyboards, and normalization pipelines insert a variation selector (U+FE0F) after an emoji. That selector sits outside the Base100 range, so a stream that looks visually identical on screen is bytewise different and fails strict decoding.
- Invalid UTF-8 byte sequence. When the bytes themselves do not form a valid UTF-8 string, the decoder reports a fatal error rather than replacing the bytes with replacement characters. This is the same fatal-UTF-8 behavior defined by the WHATWG Encoding Standard.
Comparing Base100 alternative implementations
Before switching tools, compare a few documented properties. The table below summarizes how the Lizely Base100 Encoder / Decoder lines up against the original Rust command-line tool and the Go reference library documented at pkg.go.dev. The cell values reflect publicly documented behavior in each project, not unverified claims.
| Property | Lizely Base100 tool | Original Rust CLI | Go reference library |
|---|---|---|---|
| Where the conversion runs | In the browser, no upload | Locally on the machine after Rust is installed | Locally inside a Go program |
| Accepted symbol range | Strict U+1F3F7 through U+1F4F6 only | Strict U+1F3F7 through U+1F4F6 only | Strict U+1F3F7 through U+1F4F6 only |
| Mapping formula | byte b becomes U+1F3F7 + b | byte b becomes U+1F3F7 + b | byte b becomes U+1F3F7 + b |
| UTF-8 boundary handling | Fatal validation per the WHATWG standard | Standard UTF-8 boundary at the input | Standard UTF-8 boundary at the input |
| Setup needed before use | None, runs in a browser tab | Rust toolchain required | Go toolchain required |
| Fixed size limit | 500,000 bytes or symbols per direction | Set by host machine | Set by host program |
The Lizely tool is a strong fit for readers who want the format without a toolchain and without a server round-trip. The Rust CLI is a stronger fit for batch processing large files in shell pipelines, since the browser tab has a fixed size cap. The Go library is the right choice for embedding Base100 into another Go program.
Pitfalls that break decoding after switching tools
Switching from one Base100 implementation to another is normally transparent, but a handful of common mistakes cause pasted streams to fail strict decoding.
- Adding whitespace. Even a single space between symbols pushes one code point outside the accepted range. The decoder rejects the stream rather than skipping the space.
- Variation selectors. Emoji rendering often attaches U+FE0F automatically. That selector is not part of Base100, so copy-and-paste from a colorful chat client can inject invisible characters that change the byte count.
- Font or system substitution. Some platforms swap a Base100 code point for a different emoji when copying. The byte content changes even when the visual appearance looks similar on screen.
- Truncation. The format has no length marker, so a pasted stream that drops a byte can decode to a string with a missing final byte or, for non-ASCII text where the drop leaves a multi-byte UTF-8 sequence incomplete, to an invalid UTF-8 error. Always paste the full stream.
- Encoding mismatch. If the destination is ASCII-only, Base100 symbols may be stripped entirely. In that case use Base64, hexadecimal, or another ASCII-only encoding instead.
For deeper background on the byte-to-symbol formula and how non-ASCII text expands, the Base100 Encode Cheat Sheet walks through the mapping in detail, and the original Adam Niederer Base100 repository documents the reference formula used by every conformant alternative.
Once the byte-exact workflow is in place, switching to a browser-based Base100 alternative becomes a matter of replacing the existing step with the Lizely tool: paste the text, copy the symbol stream, paste it again to decode, and verify the round-trip. Because the mapping is reversible and the tool refuses to silently rewrite bytes, an alternative that matches those rules can replace the original CLI without changing the resulting byte stream.