Base91 Validator

Base91: the compact binary-to-text encoding that squeezes more bytes per character than Base64

Base91 is a binary-to-text encoding scheme designed by Joachim Henke around the year 2000 as a more space-efficient alternative to Base64. It uses a 91-character alphabet built from printable ASCII characters, deliberately excluding the three string-sensitive characters ", ' and \ so that the encoded output is safe to drop inside double-quoted, single-quoted and backslash-aware string literals without escaping.

The headline benefit is density: where Base64 carries a 33% overhead, Base91 lands at roughly 14% overhead — every 13 bytes of input produce on average 16 output characters, a 1.23x ratio. That makes Base91 attractive for embedding binary blobs in size-constrained text channels, log files, configuration formats and long data URIs where every kilobyte matters.

Alphabet, character set and validation regex

The 91 characters cover A-Z, a-z, 0-9 and a curated set of punctuation: !#$%&()*+,./:;<=>?@[]^_`{|}~". A practical validation regex is ^[A-Za-z0-9!#$%&()*+,./:;<=>?@[\]^_`{|}~"]+$. Note that the encoding is case-sensitive and ASCII-only — Base91 strings never contain whitespace, line breaks or non-ASCII characters.

Because the alphabet is dense and irregular, decoding is more expensive than Base64: implementations typically rely on BigInt arithmetic to convert chunks of characters back to bytes. Expect Base91 decode to be measurably slower than Base64 on the same payload.

Base91 vs Base64, Z85 and Base85 (Ascii85)

• vs Base64: Base91 is roughly 14% larger than the binary input vs 33% for Base64 — more compact, but far less universally supported.
• vs Z85 (ZeroMQ, RFC 32/Z85): an 85-character alphabet designed to be JSON-safe and source-code-safe. Simpler, slightly larger output, much more standardized.
• vs Base85 / Ascii85: used by Adobe PostScript and PDF; RFC 1924 also defined an Ascii85 variant for textual IPv6 representation. About 25% overhead.
• Verdict: Base91 wins on density but loses on ubiquity. Use it only when the 14% savings actually matter and you control both encoder and decoder.

Common pitfalls and where Base91 falls short

• Not URL-safe: the alphabet contains +, /, ?, =, & and # — all reserved in URIs. You still need percent-encoding for URL contexts, which erodes the size advantage.
• Not universal: unlike Base64, browsers and standard libraries do not ship Base91 out of the box. You need a dedicated library on both ends.
• basE91 variant: Henke's original spelling is basE91; some forks (e.g. iqlusion) use slightly different alphabets — confirm both sides use the same table.
• Decode performance: BigInt-based decoders are noticeably slower than Base64's lookup-table approach for large payloads.
• Limited tooling: among Brazilian developers and most general communities, Base91 sees almost no adoption — niche encoding with niche tooling.

Libraries and ecosystem

For Node.js the base91 npm package is the most widely used implementation. Python developers reach for py-base91 or the reference C code linked from Henke's site. There are community ports for Go, Rust and Java, but none are part of any standard library — always pin a specific version and document the exact alphabet to avoid interop bugs.

FAQ

How does Base91 compare to Base64?

Base91 is more compact — about 14% overhead vs Base64's 33% — but it is far less universal. Base64 is built into virtually every language and runtime; Base91 always requires an extra library.

Is Base91 URL-safe?

No. The alphabet includes +, /, =, ? and &, which are reserved in URIs. You must percent-encode the string when embedding it in URLs, and that overhead usually wipes out the size advantage.

Is there widespread library support for Base91?

No — it is a niche encoding. There are functional libraries for Node.js (base91), Python, C and a handful of other languages, but it is not part of any standard library and tooling is limited.

When is Base91 actually worth using?

When you control both encoder and decoder, the 14% size savings versus Base64 matters (long data URIs, log files, compact transmission), and the channel is text-only ASCII-safe but not a URL. Otherwise stick with Base64.

Why exclude only ", ' and \?

Those three characters are the most common source-code string delimiters and escape characters. By excluding them, Base91 strings can be embedded directly in quoted string literals across most programming languages without needing extra escaping.