Base100 encoding on a Mac runs entirely inside the browser, requires no installation, and works in Safari, Chrome, Firefox, or any other modern macOS browser by visiting the Base100 Encoder / Decoder page. The encoder converts your UTF-8 text into a byte stream, then maps each byte to exactly one Unicode code point inside the inclusive range from U+1F3F7 through U+1F4F6 by adding the byte value to the base code point, producing a stream of 256 distinct emoji-range symbols. Decoding walks the symbols in reverse, subtracts U+1F3F7 to recover each byte, runs the recovered bytes through a strict UTF-8 decoder, and either prints the original text or reports that the input was invalid. Every step is performed by JavaScript on your Mac's CPU, so the input is never uploaded, never logged, and never leaves the device through the network tab. Because the mapping is purely a byte-to-code-point formula, the only macOS-specific concerns are font rendering, clipboard behaviour, and whether a destination app silently inserts a variation selector when you paste the symbols back.
Why a Browser Tab Beats a Native CLI on macOS
The original Base100 implementation is a Rust binary that ships in a Cargo crate on GitHub, which on macOS means installing the Rust toolchain, cloning the repository, and running a build command before a single emoji can be produced. A browser-based tool removes every one of those steps: no Homebrew dependency, no PATH configuration, no Gatekeeper warning, and no need to keep the binary up to date when the format evolves. The encoding algorithm itself is small enough to ship in a few kilobytes of JavaScript, so the page loads quickly even on a MacBook Air over a metered connection. Safari, Chrome, Firefox, and Arc all execute the same JavaScript path identically because the WHATWG Encoding Standard defines the UTF-8 boundary the same way on every browser engine, as documented at encoding.spec.whatwg.org.
For occasional one-off encoding tasks, that trade-off is unambiguous: opening a single tab costs less time than installing a Rust toolchain, and the result is identical byte-for-byte because the underlying formula is the public mapping from the upstream project. For power users who already maintain a Rust or Go environment and want to script Base100 inside a build pipeline, the command-line path documented in the AdamNiederer/base100 repository is the appropriate choice, but it is not the tool most readers are searching for when they type "base100 encode on mac".
Encode Base100 on macOS in Safari or Chrome
- Launch Safari (the default macOS browser) or any other modern browser installed on the Mac, such as Chrome, Firefox, Brave, or Arc.
- Navigate to the Base100 Encoder / Decoder page so the conversion JavaScript loads once and remains available offline for the session.
- Click the "Text to Base100" tab to expose the encoder pane; the decoder pane sits next to it and stays inactive until you switch.
- Type or paste your UTF-8 text into the input box. Standard Cmd+A then Cmd+V works inside the field the same way it does in any macOS text input, and the input is not sent anywhere over the network.
- Click the Run or Encode button to trigger the byte-by-byte mapping. The result panel fills with the symbol stream representing each UTF-8 byte of your text.
- Press Cmd+C on the result panel, or click the Copy button the page exposes, to put the exact code points on the macOS clipboard. Do not press Return, add spaces, or insert line breaks: the mapping is positional and any extra character becomes an invalid byte on decode.
- Paste the symbols into your destination - a chat app, a file, or another encoder such as the Base64 Encode / Decode tool - and verify by decoding them back before relying on the round-trip in production.
Decode Base100 Symbols Back to Text on a Mac
The reverse operation is just as important as encoding because copy-paste pipelines almost always round-trip. On the same page, click the "Base100 to text" tab, paste the unmodified symbol stream from your clipboard, and run the decoder. The page subtracts U+1F3F7 from every code point, collects the resulting bytes, and runs them through a strict UTF-8 decoder. If any character is outside U+1F3F7 through U+1F4F6 - including spaces, line breaks, ordinary punctuation, variation selectors, or mapped code points outside the 256-symbol window - the tool rejects the input instead of silently substituting U+FFFD. That strictness protects you from copying a visually similar but bytewise different stream out of a Messages thread.
What a strict decoder catches
- Spaces, tabs, and newline characters that an editor may have inserted during copy-paste.
- Variation selector U+FE0F that macOS Messages sometimes appends to emoji on paste.
- Code points that sit outside the Base100 window, including all standard emoji above U+1F4F6.
- Truncated or padded streams whose bytes do not form a valid UTF-8 sequence; the decoder reports an error rather than producing garbage.
Mac-Specific Pitfalls: Variation Selectors, Fonts, and Clipboard Behaviour
The Base100 mapping is mathematical, but what you see on a Retina display depends on the Apple Color Emoji font bundled with macOS, the version of macOS, and whether the destination app applies its own emoji substitution. Some mapped code points render as colourful pictographs on Sonoma and Sequoia, while others may appear as monochrome glyphs, fallback boxes, or unexpected symbols on older releases. Rendering differences never change the underlying code point, so copying a symbol that looks like a frog still carries the bytes you expect, but copying that symbol through a chat app that inserts U+FE0F silently breaks strict decoding downstream.
Three habits prevent most macOS round-trip failures. First, copy the Base100 output using the page's Copy button rather than selecting it with the mouse, because manual selection may omit trailing code points on very long streams. Second, paste into a plain-text destination such as TextEdit in plain mode or BBEdit before forwarding the symbols anywhere that might normalise them. Third, decode the result back to the original text on the same Mac before you treat the round-trip as reliable; if decoding fails, the bug is in the copy pipeline, not the encoder.
Byte-by-Byte Mapping Reference for Mac Users
Knowing the exact formula helps when you need to predict how big a stream will get before you paste it. The table below lists a few anchor points; every other byte sits at its offset from U+1F3F7.
| Input byte | Resulting code point | How it is computed |
|---|---|---|
| 0 | U+1F3F7 | Base offset, no addition |
| 1 | U+1F3F8 | U+1F3F7 + 1 |
| 65 (ASCII 'A') | U+1F438 | U+1F3F7 + 65 |
| 128 | U+1F477 | U+1F3F7 + 128 |
| 255 | U+1F4F6 | U+1F3F7 + 255 (top of range) |
Because the mapping is one symbol per byte, an ASCII-only message such as "hello" produces exactly five Base100 symbols. A non-ASCII message containing accents, CJK characters, or emoji produces more symbols than characters, because each Unicode character typically expands into multiple UTF-8 bytes and each byte becomes one symbol. For example, the two-byte UTF-8 encoding of "é" turns a single character into two symbols; a four-byte emoji turns one character into four symbols. Plan paste budget accordingly when you target a destination with a length cap.
Worked Example: Encoding "Hi" on a Mac
To see the formula in action, encode the two-character ASCII string "Hi" in the browser tool. The string converts to UTF-8 as the bytes [0x48, 0x69]. Byte 0x48 is decimal 72, which maps to code point U+1F3F7 + 72 = U+1F43F. Byte 0x69 is decimal 105, which maps to code point U+1F3F7 + 105 = U+1F460. The symbol stream therefore contains exactly two code points, regardless of how many glyphs macOS draws for either of them, and the decoder recovers the original "Hi" by reversing both subtractions and re-decoding the UTF-8 byte pair. The symbol count is always the byte count, never the character count, which is the single biggest source of surprise for first-time users.
Limits, Safety, and When to Pick a Different Encoding
The browser implementation caps either direction at 500,000 bytes or symbols per operation so an accidental huge paste cannot freeze the tab. Empty input is rejected on both sides, output is never silently truncated, and decoding uses fatal UTF-8 validation that surfaces an error rather than replacing bad bytes with U+FFFD. These guards are deliberate: the encoding is meant to be exact, so the tool refuses to pretend an altered stream is valid.
Base100 is also not encryption, not hashing, not signing, and not authentication. Anyone with the mapping can recover the text in seconds, and there is no checksum to detect tampering. Use a reviewed encryption format such as the AES Encryption Online tool when secrecy or tamper detection matters. Likewise, if the destination requires ASCII-only transport, prefer Base64, hexadecimal, or Base32 instead of Base100, because Base100 symbols live in the supplementary multilingual plane and many older pipes will mangle them.
Quick Workflow Summary for Mac Users
The shortest reliable path on macOS is: open the Base100 Encoder / Decoder in Safari, encode the text, copy with the page's copy button, paste into a plain-text field, decode the result back on the same page to confirm the round-trip, then forward the symbols to the destination. Skipping the decode-back verification is the single most common cause of "it looked fine but the bytes were wrong" reports, because macOS clipboard behaviour and the receiving app's text handling are the only parts of the pipeline that the encoder cannot control.
For a deeper look, see Binary to Text on iPhone: Use Safari Without an App.
For a deeper look, see CRC32 Calculator API Alternative: Run Locally in Browser.