basE91 is a binary-to-text encoding by Joachim Henke designed for maximum density among printable schemes. By packing a variable 13 or 14 bits into each character pair, it carries roughly 14 percent overhead — noticeably tighter than Base64’s fixed 33 percent. This tool encodes UTF-8 text into Base91 and decodes it back, entirely in your browser.
How it works
Base91 streams bits through an accumulator rather than using fixed groups:
- Input bytes are shifted into a bit accumulator, eight bits at a time.
- Once the accumulator holds more than 13 bits, the low 13 bits are examined. If that value is greater than 88 the encoder consumes 13 bits; otherwise it consumes 14 bits. This keeps every two-character unit within the 8281 combinations that 91 squared provides.
- The consumed value is split into two characters:
value mod 91andvalue / 91, each mapped through the 91-symbol alphabet. - Any leftover bits at the end are flushed as one or two final characters.
Decoding reverses the process, reading two characters into a value, then refilling and draining the bit accumulator a byte at a time, choosing 13 or 14 bits using the same greater-than-88 test.
Worked example and density comparison
Encoding the text test (4 bytes) produces fPNKd — five characters, compared to Base64’s six characters (dGVzdA==) for the same input. The density advantage compounds with larger payloads:
| Input size | Base64 output | Base91 output | Savings |
|---|---|---|---|
| 10 bytes | 16 chars | ~13–14 chars | ~12–15% |
| 100 bytes | 136 chars | ~117–120 chars | ~12–14% |
| 1,000 bytes | 1,336 chars | ~1,155–1,170 chars | ~13% |
The actual savings vary because Base91’s bit-packing is variable-width — whether 13 or 14 bits are consumed per pair depends on the data values. Highly compressible data (lots of zeros or repeated patterns) does not benefit more; the savings are roughly consistent regardless of content.
What the Base91 alphabet looks like
Base91 uses 91 of the 95 printable ASCII characters. The four excluded characters are the space (not printable in most contexts), the apostrophe (interferes with SQL string literals), the hyphen (ambiguous as a flag in shell commands), and the backslash (escape character in many languages). The remaining 91 symbols — letters, digits, and punctuation including &, ~, ", !, and # — appear in the output.
This choice keeps the alphabet usable in most text contexts while achieving maximum density. The trade-off is that Base91 output is not URL-safe and not safe in SQL without escaping. If the destination is a URL query string, JSON value, or SQL parameter, either escape the output or use a URL-safe encoding instead.
When to choose Base91
Base91 is best when:
- You are encoding large binary payloads (kilobytes or more) and the ~13% size reduction over Base64 is meaningful
- The output channel handles arbitrary printable ASCII without interpretation (binary-safe text protocols, email body text, log files)
- You are not constrained to an RFC-standard format
It is a poor choice when:
- The output must go directly into a URL or HTML attribute without escaping
- You need interoperability with a system that expects a standard RFC encoding (Base64, Base32, etc.)
- Compact output matters less than simplicity — Base64 is universally understood and has library support in every language
Everything runs locally in your browser — no data is uploaded.