Introduction
Base85 is a family of encodings that map 4 bytes to 5 ASCII characters, achieving 25% overhead instead of base64's 33%. But 'base85' is not one format. Ascii85 (Adobe), Z85 (ZeroMQ), and IPv6 Base85 (RFC 1924) all use different 85-character alphabets, different padding rules, and different delimiters. This tool encodes and decodes all three variants side by side, showing the output length, overhead percentage, and which variant is most efficient for your specific input. Paste text and compare instantly, all in your browser.
What this tool does
- Encode input text to Ascii85 (Adobe), Z85 (ZeroMQ), and IPv6 Base85 (RFC 1924) simultaneously, showing all three outputs side by side
- Decode input from any of the three variants, with automatic stripping of Adobe delimiters (<~ ~>) and whitespace
- Display encoded length, overhead percentage, and byte count for each variant, with a 'most efficient' indicator
- Show a property comparison table covering alphabet, zero-group handling, padding rules, and delimiters for all three variants
- Handle Ascii85's 'z' shorthand for all-zero 4-byte groups, and Z85's input length padding to multiples of 4 bytes
- Run entirely client-side: input text and encoded outputs never leave your browser
How this tool works
The tool computes all three encodings in parallel using pure TypeScript. For each variant, the input text is converted to UTF-8 bytes, then processed in 4-byte chunks. Each chunk is treated as a 32-bit big-endian integer, which is divided by 85 five times to produce 5 base-85 digits. Each digit indexes into the variant's 85-character alphabet to produce the output character.
Ascii85 (Adobe) uses characters 33 through 117 (exclamation point through lowercase u). It wraps output in `<~` and `~>` delimiters. When a full 4-byte chunk is all zeros, it uses the single character `z` instead of five exclamation points, saving space on sparse data. Trailing partial chunks produce fewer than 5 characters with no padding.
Z85 (ZeroMQ) uses a different alphabet: `0-9a-zA-Z.-:+=^!/*?&<>()[]{}@%$#`. It requires input length to be a multiple of 4 bytes, so the tool pads with zeros and tracks the original length. There is no `z` shorthand and no delimiter wrapping.
IPv6 Base85 (RFC 1924) uses yet another alphabet: `0-9A-Za-z!#$%&()*+-;<=>?@^_`{|}~`. It handles partial trailing chunks by truncating the output, similar to Ascii85 but without the `z` shorthand or delimiters.
The size comparison panel shows the encoded character count and overhead percentage for each variant, and identifies which one produces the shortest output for the given input.
How Base85 variants work (Ascii85, Z85, IPv6)
The base-85 concept comes from representing 4 bytes (2^32 possible values, up to 4,294,967,296) as 5 base-85 digits (85^5 = 4,437,053,125, which is just large enough). This gives 5/4 = 125% of the original size, or 25% overhead, compared to base64's 4/3 = 133% (33% overhead).
Ascii85 originated in the PostScript language, specified in the Adobe PostScript Language Reference (also called 'btoa' encoding). Adobe added the `<~` and `~>` delimiters and the `z` shorthand for all-zero groups. It is used in PDF files for embedding binary streams.
Z85 is defined in the ZeroMQ RFC 32 specification for encoding CurveZMQ keys. It was designed to be URL-safe and filesystem-safe, avoiding characters that need escaping in URLs or have special meaning in shells. The alphabet is a carefully chosen subset that excludes quotes, backslashes, and other problematic characters.
IPv6 Base85 was proposed in RFC 1924 as an alternative representation for IPv6 addresses. An IPv6 address is 128 bits, which maps neatly to 20 base-85 characters (instead of the standard 32 hex characters or the longer colon-separated notation). The RFC was published on April 1, 1996 and is classified as an April Fools' joke, but the encoding itself is valid and occasionally appears in networking contexts.
All three variants share the same mathematical core (4 bytes to 5 base-85 digits) but differ in alphabet selection, padding, zero-group handling, and framing. The choice of alphabet matters for interoperability: a Z85-encoded string cannot be decoded as Ascii85 and vice versa.
How to use this tool
- Select Encode or Decode mode using the toggle buttons
- Type or paste text in the input field. For encoding, the tool converts it to UTF-8 bytes and encodes with all three variants
- For decoding, paste an encoded string. The tool attempts to decode it with all three variants (Ascii85 strips <~ ~> delimiters automatically)
- Check the size comparison panel: it shows encoded length, overhead percentage, and which variant is most efficient for your input
- Review the variant comparison table to understand the differences in alphabet, zero-group handling, padding, and delimiters
- Click Swap encode/decode to reverse the operation
Real-world examples
Encoding 'Man' (3 bytes) with all three variants
Input: `Man` (3 bytes: 0x4D 0x61 0x6E). The 4-byte chunk is padded with a zero byte to 0x4D616E00. Ascii85 produces `<~9jqo^~>` (5 characters plus delimiters, since the last byte is padding and one character is dropped). Z85 produces 5 characters from its alphabet. IPv6 Base85 produces 4 characters (one dropped for the padding byte). The overhead panel shows all three variants at roughly 67% overhead for this short input, since fixed overhead dominates at small sizes.
Encoding a 16-byte input to compare efficiency
Input: 16 bytes of text. All three variants produce 20 characters (4 chunks of 4 bytes, each mapping to 5 characters). Ascii85 adds 4 delimiter characters (<~ and ~>), making it 24 total. Z85 and IPv6 Base85 produce exactly 20 characters with no delimiters. The overhead panel shows Z85 and IPv6 Base85 at +25.0%, while Ascii85 is at +50.0% due to the delimiters. For larger inputs, the delimiter overhead becomes negligible.
The 'z' shorthand in Ascii85
Input: 4 zero bytes (0x00 0x00 0x00 0x00). Ascii85 encodes this as the single character `z` instead of `!!!!!` (five exclamation points). This saves 4 characters per all-zero group. Z85 and IPv6 Base85 encode the same input as 5 characters from their respective alphabets (the first character, repeated 5 times). For data with many zero runs (like sparse binary files), Ascii85's `z` shorthand can significantly reduce output size.
Decoding an Adobe Ascii85 string
Paste `<~9jqo^~>` in decode mode. The tool strips the `<~` prefix and `~>` suffix, removes whitespace, and decodes the 5 characters `9jqo^` back to 4 bytes. If you include the `z` shorthand in the input (e.g., `<~z~>`), the tool expands it to 4 zero bytes. Invalid characters (those outside the 85-character alphabet) are silently skipped during Ascii85 decoding, while Z85 returns an error for invalid characters.
Z85 input length requirement
Z85 requires input to be a multiple of 4 bytes. If you encode 5 bytes, the tool pads to 8 bytes (2 chunks) and produces 10 Z85 characters. On decode, Z85 expects input to be a multiple of 5 characters. If you provide 7 characters, the tool processes the first 5 and ignores the remaining 2. This is stricter than Ascii85, which handles partial chunks by truncating the output.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Ascii85 (Adobe) | 85-char alphabet, 25% overhead, z shorthand | PDF and PostScript binary streams |
| Z85 (ZeroMQ) | 85-char alphabet, 25% overhead, multiple-of-4 required | ZeroMQ CURVE key encoding |
| IPv6 Base85 (RFC 1924) | 85-char alphabet, 25% overhead, no delimiters | Compact IPv6 address representation (April Fools RFC) |
| Base64 | 64-char alphabet, 33% overhead | Email MIME, JWT, web data URIs |
| Base32 | 32-char alphabet, 60% overhead | Case-insensitive systems, DNSSEC |
Limitations or considerations
All three Base85 variants are encodings, not encryption. They provide zero confidentiality. The output is trivially reversible by anyone with the alphabet.
The 85-character alphabets include characters that are not URL-safe (Ascii85 uses `!"#$%&'()*+,-./` which all require percent-encoding in URLs). Z85 was specifically designed to avoid this problem. If you need URL-safe encoding, use Z85 or Base64 Encode/Decode with URL-safe alphabet.
Ascii85's `z` shorthand only applies to full 4-byte all-zero groups. Partial chunks at the end of the input do not get the `z` treatment even if they contain zeros. This means the space savings depend on the alignment of zero runs within the data.
Z85's requirement for input length to be a multiple of 4 bytes means the tool pads with zeros, which can produce extra output characters that decode to padding bytes. The original length is not embedded in the encoding, so the decoder must know how many padding bytes to strip. This is a known limitation of Z85 compared to Ascii85's truncation approach.
For single-variant encoding (not comparison), use the dedicated Ascii85 Encode/Decode or Base85 Encode/Decode tools.
Frequently asked questions
What is the difference between Ascii85, Z85, and IPv6 Base85?
All three encode 4 bytes as 5 base-85 digits (25% overhead), but they use different 85-character alphabets. Ascii85 (Adobe) uses chars 33-117, adds <~ ~> delimiters, and has a 'z' shorthand for all-zero groups. Z85 (ZeroMQ) uses a URL-safe alphabet and requires input to be a multiple of 4 bytes. IPv6 Base85 (RFC 1924) uses another alphabet with no delimiters or zero shorthand. A string encoded with one variant cannot be decoded with another.
Why does Base85 have 25% overhead instead of Base64's 33%?
Base85 maps 4 bytes (32 bits) to 5 characters from an 85-character alphabet. Since 85^5 = 4,437,053,125 which exceeds 2^32 = 4,294,967,296, five base-85 digits can represent any 4-byte value. The output is 5/4 = 125% of the input, or 25% overhead. Base64 maps 3 bytes to 4 characters from a 64-character alphabet (64^4 = 16,777,216 = 2^24), giving 4/3 = 133% or 33% overhead.
What is the 'z' shorthand in Ascii85?
In Adobe Ascii85, when a full 4-byte chunk is all zeros (0x00000000), instead of encoding it as five exclamation points (!!!!!), the encoder outputs a single 'z' character. This saves 4 characters per all-zero group. It is particularly useful for encoding sparse data with many zero regions, such as certain PDF streams.
Is RFC 1924 (IPv6 Base85) a real standard?
RFC 1924 was published on April 1, 1996 as an April Fools' joke proposing a compact base-85 representation for IPv6 addresses (20 characters instead of 32 hex characters). The encoding math is valid, but the RFC is not a serious standard. The format occasionally appears in networking discussions and CTF challenges but is not used in real IPv6 implementations.
Which Base85 variant should I use?
For PDF or PostScript contexts, use Ascii85 (Adobe). For ZeroMQ CURVE keys, use Z85. For general-purpose encoding where you want the 25% overhead advantage, Z85 is the most practical choice because its alphabet is URL-safe and filesystem-safe. For comparison with base64, see the Base64 Encode/Decode tool.
Conclusion
Base85 encoding trades a larger alphabet for lower overhead: 25% instead of base64's 33%. The three variants compared here (Ascii85, Z85, IPv6 Base85) share the same mathematical core but differ in alphabet, padding, and framing. This tool shows all three side by side so you can pick the right one for your use case. For dedicated Ascii85 encoding, use the Ascii85 Encode/Decode tool. For general base85, see Base85 Encode/Decode. For the more common base64, use Base64 Encode/Decode.