Base91 Encoder / Decoder

Compact binary-to-text encoding — ~23% overhead vs Base64's ~33%.

Direction

Input

Drop a binary file to encodeEncodes raw bytes to Base91 — images, binaries, anything.

Output

What is Base91?

Base91 is a binary-to-text encoding scheme that uses 91 printable ASCII characters. It achieves approximately 23% overhead relative to the binary input, compared to Base64's 33% overhead, making it more compact for arbitrary binary data. Every group of 13 or 14 bits maps to two characters from the 91-character alphabet — so Base91-encoded output is meaningfully shorter than Base64 for the same input. This makes it useful in situations where minimising encoded size matters, such as embedding binary data in source code, transmitting payloads over character-limited channels, or storing compact checksums.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Packing binary data into text where every byte of overhead counts and the channel is not a URL.
Comparing encoding efficiency against Base64 for a size-sensitive payload.
Decoding a Base91 blob produced by a tool that chose density over compatibility.
Demonstrating why a larger alphabet buys a better ratio than Base64 manages.
Encoding a compressed archive for embedding in a text-only transport.

Frequently Asked Questions

How much better than Base64 is it?: Base91 averages about 23% overhead against Base64's 33%, because it packs 13 bits into two characters where Base64 packs 6 bits into one. On a megabyte of binary that is roughly 100 KB saved — worthwhile when the transport is genuinely text-only.
Why 91 characters?: It is the printable ASCII set minus the ones that cause trouble: the hyphen, the backslash and the apostrophe are excluded so the output can sit inside quoted strings without escaping. 91 is simply what remains.
Why is Base64 still the default?: Universality. Base64 is in every standard library, every protocol and every RFC; Base91 is a single 2005 implementation with no standards-track document. Choosing it means both ends must agree explicitly, which is often not worth 10%.
Is the output URL-safe?: No. The alphabet includes `+`, `&`, `=`, `#`, `?` and `/`, all of which are reserved in a URL — so percent-encoding it would erase the size advantage entirely. Use Base64URL for anything that goes in a query string.
Why is the output length variable?: Because the packing is not aligned to byte boundaries: 13 bits at a time means the number of characters depends on the actual bit values, not just the input length. Base64 always emits exactly four characters per three bytes; Base91 does not.
Is basE91 a standard?: No — it is one developer's format with a reference implementation, not an RFC. That is a real constraint: unlike Base64, you cannot assume the other end can decode it without shipping a matching implementation.

Common errors and gotchas

Assuming the output is URL-safe. The alphabet includes characters that must be percent-encoded, which erases the size advantage.
Expecting a fixed expansion ratio. The encoding is variable-length, so output size depends on the input bytes themselves.
Treating it as a standard. There is no RFC, and implementations differ enough that round-tripping between them can fail.
Choosing it for interoperability. Base64 is supported everywhere and Base91 is supported almost nowhere.
Overlooking that the gain over Base64 is only a few per cent, which rarely justifies the compatibility cost.