Base85 / Ascii85 Encoder and Decoder

What Ascii85 means on this page

Base85 is a family of encodings that represents four input bytes with five printable characters. This page implements the Ascii85 form associated with Adobe PostScript and PDF conventions. Its regular digits are the consecutive ASCII characters from ! through u. Because 85 to the fifth power is slightly larger than 2 to the thirty-second power, five such digits can carry one unsigned 32-bit group.

Adobe-style Ascii85 may wrap a complete value between <~ and ~>. It may also replace an entire four-byte zero group with the single character z. Those features are not universal across every Base85 variant, so the page exposes them explicitly. Encoding can add delimiters and use z; decoding accepts wrapped or unwrapped values, ignores defined ASCII whitespace, and validates that z appears only where a new five-character group could begin.

The last group needs special handling. If one, two, or three input bytes remain, the encoder pads a temporary 32-bit block with zero bytes, computes five characters, and emits only two, three, or four of them. The decoder pads a final group of two to four characters with u and removes the extra bytes. A one-character final group cannot carry even one byte and is rejected.

How to use the Ascii85 converter

1. Choose Encode for normal text or Decode for an existing Ascii85 value.
2. When encoding, enable Adobe delimiters if the target format expects <~ and ~>. Disable them for a raw Ascii85 field.
3. Leave z shorthand enabled for compact Adobe-compatible output, or disable it when a consumer requires every zero block to be expanded to five characters.
4. Paste encoded input with ordinary ASCII whitespace if necessary. The decoder ignores spaces, tabs, carriage returns, line feeds, and form feeds but validates all other characters.
5. Use a round trip and the published Hello vector to verify that another implementation agrees about delimiters, partial groups, and shorthand.

Ascii85 and Adobe boundary examples

Ascii85 has more syntax than Base32 or Base64. These examples show plain output, Adobe delimiters, partial groups, ignored ASCII whitespace, and the special z token.

Ascii85 syntax accepted by the decoder

A wrapped value must contain both Adobe delimiters and they must surround the entire non-whitespace content. A start marker without an end marker, nested markers, or extra data after the end marker is invalid. An unwrapped value must not contain either marker.

Regular digits range from ASCII code 33 (!) through 117 (u). The special z token is accepted only when no regular digits are waiting in the current group. This implementation does not accept the y shorthand used by some btoa variants, because y is not part of Adobe Ascii85.

• ASCII whitespace is ignored during decoding; arbitrary Unicode whitespace is not silently removed.
• A regular group contains exactly five characters and produces four bytes.
• The final group may contain two, three, or four characters, but never one.
• The value uuuuu exceeds 0xFFFFFFFF and is rejected as an overflowing group.
• The z shorthand expands to four zero bytes only at a group boundary.

How Ascii85 encodes full and partial groups

For each four-byte group, the encoder constructs a 32-bit unsigned value in big-endian order. It divides that value by 85 repeatedly to obtain five base-85 digits, then adds 33 to each digit so it falls in the printable ! through u range. A zero value would normally become !!!!!, but Adobe’s z shorthand may replace that complete five-character sequence.

A partial group is padded with zero bytes only for the arithmetic. If n source bytes are present, the encoder emits n plus one characters and discards the remaining temporary digits. The decoder reverses this by padding the final characters with u, decoding a full numeric group, and keeping one fewer byte than the number of original characters. This rule is why blindly padding with ! would produce the wrong result.

Decoder overflow checks are important because 85^5 permits values larger than a 32-bit word. A five-character sequence can be made entirely from legal symbols and still exceed 4,294,967,295. The converter reports that condition instead of wrapping the number and producing unrelated bytes.

Where Adobe-style Ascii85 appears

Ascii85 is most relevant when interoperating with formats that already define it. It is denser than hexadecimal and can remain readable ASCII, but its punctuation-heavy alphabet is not naturally URL-safe.

Ascii85 errors and ambiguous Base85 names

The label Base85 does not identify one universal alphabet. Z85, RFC 1924’s IPv6 representation, btoa, and Adobe Ascii85 differ in symbols, wrappers, shorthand, or block requirements. A value from one variant may use legal-looking characters yet decode differently or fail here.

This page’s errors are intentionally specific to Adobe-style Ascii85. It accepts whitespace and z, but not y; it permits partial final groups, but not a single trailing digit; and it accepts delimiters only as a matched outer pair.

• A z after one or more pending digits is invalid because it cannot split a group.
• A lone <~ or ~> marker is invalid.
• Characters after u, except the standalone z shorthand, are outside the alphabet.
• A one-character tail cannot encode a byte.
• Decoded binary bytes may be valid Ascii85 but invalid UTF-8 text.

Ascii85 compared with Z85 and Base64

Ascii85 and Z85 both use eighty-five symbols, but Z85 uses a different carefully selected alphabet, requires input lengths divisible by four, and has no Adobe delimiters or z shorthand. They are not interchangeable despite sharing the Base85 name.

Base64 is less dense but has a far more common interoperable standard. Base64url further avoids URL-reserved + and /. Ascii85 uses many punctuation characters, so it is best kept in formats that explicitly specify it.