Base100 encoding on Windows works in any modern browser without installing software: open Edge, Chrome, or Firefox, load the Base100 Encoder / Decoder, and the tool converts each UTF-8 byte of your input into one Unicode code point drawn from the inclusive range U+1F3F7 through U+1F4F6. The mapping is the original byte-to-emoji formula introduced by Adam Niederer's Base100 project, in which byte value 0 becomes U+1F3F7, byte value 1 becomes U+1F3F8, and byte value 255 becomes U+1F4F6, producing a single emoji-range symbol per byte with no padding, delimiter, or checksum. Every conversion step runs locally in the browser tab, so no characters or symbols leave your Windows PC. Windows 10 and 11 ship with the Segoe UI Emoji color font, so the output usually renders as recognizable pictographs rather than tofu boxes. To reverse a stream, paste the exact unmodified symbol sequence back into the same page, choose Base100 to text, and run decode — the decoder enforces strict validation and rejects spaces, line breaks, variation selectors, or any code point outside the 256-symbol range, reporting an error instead of silently inserting replacement characters when the bytes cannot be reconstructed as valid UTF-8.
How to encode and decode Base100 in your Windows browser
Windows does not ship with a built-in Base100 encoder, but Edge, Chrome, and Firefox all expose a JavaScript engine that runs the byte-to-emoji mapping in the browser tab itself. The Base100 Encoder / Decoder uses the WHATWG Encoding Standard for the UTF-8 boundary and Adam Niederer's reference mapping for the byte-to-code-point step, so the output matches any other conformant implementation of the format. Use these steps to encode or decode on a Windows 10 or 11 PC.
- Launch Edge, Chrome, or Firefox. All three ship with full BMP and supplementary-plane Unicode support on Windows 10 and 11.
- Navigate to the Base100 Encoder / Decoder page and let the JavaScript load fully before interacting.
- Choose Text to Base100 when you want to encode UTF-8 text into emoji symbols, or Base100 to text when you want to recover the original string from a symbol stream.
- Type your text into the input box, or paste it from the clipboard with Ctrl+V.
- Click the Encode button (or Decode, if you are reversing a stream). Encoding converts the input string to UTF-8 bytes and maps each byte to one code point by adding the byte value to U+1F3F7.
- Copy the output stream. Use the page's copy button if available, or select the text and press Ctrl+C. Do not add spaces, line breaks, or emoji variation selectors — the decoder treats them as invalid.
- To verify the round-trip, switch the mode back to Base100 to text, paste the same stream, and decode. The recovered text should be byte-identical to the original UTF-8 input.
If decoding fails, the most common cause on Windows is a variation selector appended by a chat application, a clipboard manager, or a normalization step. Copy the stream again from a plain-text source such as Notepad in Windows 11 or the browser's source view and try once more.
Comparing browser, PowerShell, and Notepad on Windows for Base100
| Windows tool | Native Base100 mapping | UTF-8 handling | Runs locally | Strict decode validation |
|---|---|---|---|---|
| Edge / Chrome / Firefox (with web tool) | Implemented in JavaScript | WHATWG standard | Yes (in-tab) | Yes — rejects out-of-range and invalid UTF-8 |
| PowerShell 7 | None built in | Yes, but no Base100 cmdlet | Yes | No native Base100 pipeline |
| Windows Terminal + PowerShell | None built in | Yes | Yes | No |
| Notepad (Windows 11) | None | Yes, explicit UTF-8 save | Yes | No |
| Notepad++ | None | Yes | Yes | No |
The table is purely qualitative — exact output lengths depend on the specific UTF-8 byte sequence you process, and for your own input the figures come directly from the Base100 Encoder / Decoder. PowerShell and Windows Terminal can echo emoji to the console, but neither has a cmdlet or built-in function that implements the Base100 mapping. Writing a custom encoder in PowerShell is slower and easier to misimplement than loading a tested web tool that follows the reference Rust project's formula documented at AdamNiederer/base100 on GitHub. Notepad and Notepad++ display emoji in the editing buffer but offer no encoding operation, so they cannot convert text into a Base100 stream on their own. A browser page, by contrast, runs the mapping in milliseconds, copies the result to the Windows clipboard, and refuses to decode any tampered input — a useful safety property when the stream travels through chat apps or clipboard managers that may inject extra characters.
Windows emoji rendering and the Segoe UI Emoji font
Windows 10 introduced the Segoe UI Emoji color font, and Windows 11 expanded coverage through Segoe UI Variable. Most of the Base100 output range, U+1F3F7 through U+1F4F6, falls inside the supplementary plane, so these systems can render the symbols as colorful pictographs when DirectWrite is enabled (the default since Windows 8.1). A few edge code points appear as monochrome glyphs, decorative boxes, or unexpected shapes depending on the active font, the browser version, and the display scaling. This visual variation is harmless for the encoding itself — the underlying code points are still byte-identical — but it does affect readability when a human tries to spot-check a Base100 stream visually.
If you see tofu boxes (□) instead of emoji, the most likely cause is a missing font on an older Windows release, a remote-desktop session with reduced font support, or a browser configured to fall back to a non-emoji font. Installing Segoe UI Emoji, switching to a current Edge or Chrome build, or pasting the stream into a chat application that bundles its own emoji font usually restores the visual representation. None of these rendering differences alter the byte stream, so a correctly copied Base100 sequence decodes back to the original text even when the on-screen glyphs look unusual.
Windows pitfalls that break strict Base100 decoding
Base100 decoding is strict by design. The Base100 Encoder / Decoder reads the pasted stream by Unicode code point, checks that every code point falls inside U+1F3F7 through U+1F4F6, subtracts U+1F3F7 to recover each byte, and runs a fatal UTF-8 validator on the resulting byte sequence. Any deviation produces an error rather than a partial result. On Windows, the most common sources of deviation are:
- Variation selectors appended by chat clients. Some Windows apps add U+FE0F (variation selector-16) to emoji-range characters for presentation. Strict Base100 rejects those code points because they fall outside the 256-symbol range.
- Clipboard managers that insert spaces. Clipboard history utilities occasionally inject a space between characters. Strict Base100 rejects spaces.
- Line wraps added by word processors. Pasting a stream into WordPad or Outlook can introduce line breaks at column boundaries. Strict Base100 rejects newlines.
- Substituted code points from older emoji fonts. Legacy fonts can replace a code point with a different one. The stream then fails validation even though the substitution is invisible on screen.
- Normalization to NFC or NFKC. Unicode normalization can fold two code points into a precomposed one. Base100 bytes are not precomposed, so normalization breaks the round-trip.
When interoperability matters more than convenience, copy the stream through a plain-text source such as Notepad in Windows 11, which preserves UTF-8 byte sequences without modification, and verify the paste length matches the source before decoding.
When Base100 is the wrong choice on Windows
Base100 is a reversible byte encoding, not encryption, not hashing, not compression, and not authentication. Anyone who knows the mapping can recover the original bytes, and there is no checksum that detects accidental or malicious changes inside a syntactically valid stream. For passwords, API tokens, private keys, or any other secret material, use a reviewed authenticated encryption format — for example the AES-256-GCM tool in this category, or a password manager with a published threat model.
When the destination channel is restricted to ASCII characters — for example, an environment variable, an SMTP header, a legacy database column, or a configuration file that strips non-ASCII bytes — Base100 will not survive the trip because every Base100 symbol is a supplementary-plane code point well above U+007F. In those cases, Base64 Encode / Decode, Base32 Encode / Decode, or Text To HEX are usually more compatible because they produce only printable ASCII. Base100 fits best on Windows when the destination is a Unicode-aware surface — a chat message, a markdown document, a code snippet in a GitHub issue, or a JSON string — and when the human-readable emoji stream is itself the point of the exercise.
Finally, remember that Base100 encodes UTF-8 bytes, not characters. A single accented letter, CJK ideograph, or supplementary-plane emoji in the original input expands to multiple Base100 symbols because each UTF-8 byte becomes one code point. The 500,000-symbol cap on the page protects the browser from freezing on a huge paste, so for very large inputs, encode in chunks and confirm each chunk round-trips before continuing.
If you're weighing options, Gzcompress Online on Windows: Run It in Edge or Chrome covers this in detail.
If you're weighing options, Base100 Encode Safe: A Byte-Exact Workflow covers this in detail.