Base100 encodes every UTF-8 byte of your text as a single code point from U+1F3F7 through U+1F4F6, so encoding large text means producing one emoji-range symbol per byte with no padding, delimiter, checksum, or compression. The mapping runs entirely in your browser, and the tool caps either direction at 500,000 bytes or symbols so a runaway paste cannot freeze the tab. Because the rule is purely byte-level, the size of the resulting symbol stream is determined by the UTF-8 byte count of your original input, not by the number of characters, words, or grapheme clusters you typed. Ordinary ASCII text produces one symbol per character, but accented letters, CJK characters, and emoji expand to multiple UTF-8 bytes and therefore multiple Base100 symbols. This is why a 10,000-character document in a Latin alphabet can encode to roughly 10,000 symbols, while a 10,000-character CJK passage commonly encodes to 30,000 or more. When you need a predictable size relationship for large text, only the byte count of the input is reliable.
How the byte mapping scales with input size
The Base100 formula is straightforward: for each byte b in the UTF-8 representation of the text, the encoder emits the code point U+1F3F7 plus b. Byte zero becomes U+1F3F7, byte one becomes U+1F3F8, and byte 255 becomes U+1F4F6, so the range spans exactly 256 consecutive code points in the supplementary multilingual plane. The mapping has no header, no length marker, no padding, and no checksum, which means every symbol in the output is meaningful: changing a single symbol changes exactly one byte of the original text. To see the formula in action, take the ASCII letter "A", which is UTF-8 byte 65. Add that to the offset: U+1F3F7 + 65 = U+1F438. So "A" encodes to U+1F438, and decoding subtracts 65 to recover the byte. Because the rule is purely arithmetic, there is no lookup table, no alphabet, and no padding to manage, and the same byte always produces the same symbol.
This arithmetic simplicity is what makes Base100 behave predictably for large text. The output length equals the input byte count, and there is no expansion or contraction beyond the one-to-one mapping. When you plan to base100 encode large text with the in-browser tool, the practical question is how many bytes your text actually contains after UTF-8 encoding, because that is the number that sets the output length and the number that determines whether you will hit the 500,000 symbol cap.
Why non-ASCII text expands the output
Base100 counts bytes, not characters, and that distinction is the main reason large text can grow when you encode it. The Unicode characters you see on screen are encoded as one, two, three, or four UTF-8 bytes depending on the code point value, and every one of those bytes becomes a Base100 symbol. A short string in a non-Latin script can therefore encode to a longer Base100 stream than a longer string written in plain ASCII.
| Input character type | Typical UTF-8 bytes per character | Base100 symbols per character | Output growth vs ASCII |
|---|---|---|---|
| Plain ASCII (U+0000 to U+007F) | 1 byte | 1 symbol | Baseline (1.0x) |
| Two-byte UTF-8 characters (U+0080 to U+07FF) | 2 bytes | 2 symbols | 2x larger |
| Most CJK, Arabic, Cyrillic extended (U+0800 to U+FFFF) | 3 bytes | 3 symbols | 3x larger |
| Astral plane characters and emoji (above U+FFFF) | 4 bytes | 4 symbols | 4x larger |
The byte counts in this table come from how the UTF-8 specification defines each range, as documented in the WHATWG Encoding Standard. The actual byte count for any specific string depends on the exact code points present. A French resume with accented letters, a Japanese article, and a Russian novel all expand according to these bands, and so do the small emoji icons people sometimes insert into otherwise ASCII text. If your large text is mixed, the simplest way to estimate the Base100 output size is to count the UTF-8 bytes of the input directly rather than counting visible characters.
How to base100 encode large text
The encoder follows three explicit steps, and following them in order is what keeps large pastes clean. Each step maps directly to a documented product behavior rather than an inferred one.
- Open the Base100 Encoder / Decoder, choose the Text to Base100 mode, paste or type the UTF-8 text you want to encode, and run the encoder. Each UTF-8 byte is mapped to one code point in the U+1F3F7 to U+1F4F6 range using the formula U+1F3F7 plus the byte value.
- Copy the resulting symbol stream exactly as produced. Do not insert spaces, do not add line breaks, and do not let a chat app or editor add variation selectors or other decorative code points during the copy.
- To reverse the process, switch the tool to Base100 to text, paste the unmodified stream, and run the decoder. If any symbol falls outside the exact range, or if the recovered bytes do not form a valid UTF-8 sequence, the decoder reports an error instead of producing a partial or corrupted string.
For a large paste, the only operational difference from a short one is that you should expect the output to be roughly as long as the UTF-8 byte count of the input, and you should plan around the 500,000 symbol ceiling before you start. Anything that alters the stream during copy will fail strict decoding, which is intentional rather than a bug.
Working within the 500,000 symbol limit
The page enforces a 500,000-byte limit on the text input and a 500,000-symbol limit on the Base100 input, so the cap is symmetrical on both sides. Empty input is rejected, output is never silently truncated, and the boundary is checked before any heavy work runs. In practice, this means a single document of up to about 500 KB of UTF-8 text can be encoded in one pass, which covers most articles, code files, configuration dumps, and book chapters without splitting. If you need to encode more than 500,000 bytes, split the input into chunks that each fit under the limit and concatenate the resulting symbol streams on the receiving side, then decode each chunk in turn. Splitting is safe because the mapping is purely local: no chunk carries a header or footer, and the decoder reconstructs text by reading code points and validating UTF-8 independently.
Keep in mind that the limit applies to the byte count of the text, not the character count, so a 500,000-character ASCII file fits comfortably while a 500,000-character CJK file at roughly three bytes per character will exceed the cap. When a paste is near the limit, trim it before encoding rather than relying on the tool to handle the overflow, because the tool will reject the input rather than producing a partial result.
Decoding large Base100 streams back to text
Decoding is the inverse of the same byte formula. The decoder reads input by Unicode code point rather than UTF-16 code unit, which matters because Base100 lives in the supplementary plane where one JavaScript character does not equal one code point in older string APIs. Every symbol must fall inside the inclusive range from U+1F3F7 to U+1F4F6, and its byte value is recovered by subtracting U+1F3F7. After all bytes are collected, a strict UTF-8 decoder reconstructs the text, and any invalid byte sequence causes a fatal error rather than a silent replacement character.
This strict behavior matters for large text because copying through messengers, rich-text editors, or normalization pipelines can insert a variation selector, a zero-width joiner, a soft hyphen, or stray punctuation that looks similar on screen but breaks the byte math. A pasted stream that decodes to garbage or fails outright is almost always a sign that the stream was altered in transit. To recover the original text, recopy the symbol stream from the encoder using a plain-text channel and paste it directly into the decoder without letting any intermediate tool reformat it. If you control both ends, prefer the original code points over visually similar substitutes, since rendering varies across operating systems and fonts but the mathematical mapping inside a conforming string does not change.
When another encoding fits large text better
Base100 is a reversible byte encoding, not a compression, encryption, or transport format, so it is not always the best fit for large text. If the destination is ASCII-only, Base64, base64url, Base32, Base58, or plain hexadecimal will travel through more systems without alteration, because Base100 symbols live in an emoji range that some servers, terminals, and search engines can strip or normalize. If the goal is smaller files, Base100 does not shrink data; the output is at least as large as the UTF-8 input and often larger for non-ASCII scripts, so a compressor such as gzip will produce a much shorter artifact. If the goal is secrecy or tamper detection, Base100 is the wrong tool entirely, since anyone who knows the mapping can recover the bytes and there is no checksum to detect modifications; use a reviewed encryption or authenticated format instead.
For puzzle messages, demos, and cases where the goal is to make a payload visually distinctive, however, Base100 encoding for large text works exactly as the byte mapping describes, and the in-browser Base100 Encoder / Decoder keeps the conversion local so no paste is uploaded. The original Adam Niederer Base100 project documents the emoji mapping on GitHub, and the WHATWG Encoding Standard defines the UTF-8 behavior the decoder relies on at the text boundary.
If you're weighing options, Gzcompress Online Large Text: Handle Big UTF-8 Payloads covers this in detail.
If you're weighing options, Binary to Text for Beginners: A First Hour Walkthrough covers this in detail.