Ascii85 & Base85 Encoder

A way to write any data, such as text, an image or a key, using 85 printable characters. Every 4 bytes become 5 characters, so the result is only 25% longer than the data. Ascii85 is Adobe's name for it, from PostScript and PDF; Base85 is the general name, and Z85 and RFC 1924 are the same idea with different alphabets.

It's shorter. Base64 turns 3 bytes into 4 characters, 33% longer than the data; Base85 turns 4 bytes into 5, 25% longer. The cost is its alphabet: Ascii85 uses quotes, backslashes and angle brackets, which need escaping in JSON, XML, HTML and source code. Z85 was designed to avoid the worst of them.

All three turn 4 bytes into 5 digits from 0 to 84; they differ in which character stands for each digit. Ascii85 uses the ASCII characters ! to u in order, adds z for four zero bytes and wraps the result in <~ and ~>. Z85, from ZeroMQ, uses 0–9, a–z, A–Z and 23 symbols chosen to be safe inside quoted strings. RFC 1924 uses 0–9, A–Z, a–z and a different set of symbols; Git and Python's base64.b85encode use the same alphabet.

They're Ascii85 extras. A z stands for four zero bytes, instead of !!!!!, and it can only appear between groups, never inside one. A y stands for four spaces, but only in btoa, from version 4.2 on; Adobe's decoders reject it. Adobe wraps the data in <~ and ~>, and PDF streams end with ~> alone. Whitespace anywhere is ignored.

When the bytes don't divide into fours, the last group is padded with zero bytes, encoded, and one character is dropped for each byte of padding. So 1 leftover byte becomes 2 characters, 2 become 3, and 3 become 4. Decoding does the reverse: it fills the missing characters with the highest digit (u in Ascii85), then throws away the extra bytes. A single leftover character can't come from any bytes, so it's an error.

Ascii85 is in PostScript and PDF, where the ASCII85Decode filter keeps binary data like images and fonts as plain text. Git writes binary files in patches with RFC 1924's alphabet, and so does Mercurial. ZeroMQ writes its CURVE security keys in Z85, 40 characters for 32 bytes. Python has it built in as base64.a85encode, b85encode and, from Python 3.13, z85encode.

The usual culprits: a character outside ! to u (lowercase v, w and x never appear, and neither do curly quotes that a word processor put in); a z in the middle of a group; one lone character left at the end; or a group worth more than 2³² − 1, like s8W-" or anything above it. The decoder here points to the exact character.

It was published on 1 April 1996 as a joke: "A Compact Representation of IPv6 Addresses" proposed writing every IPv6 address as a 128-bit number in base 85, always 20 characters. Nobody writes addresses that way, but the encoding works, and its alphabet became the usual one for Base85 outside PDF.

In Python: base64.a85decode(data, adobe=True) for Adobe's form, which must end in ~> (the <~ is optional), base64.a85decode(data) for bare data, base64.b85decode for Git and RFC 1924, and base64.z85decode on Python 3.13 or later. JavaScript has no built-in Base85, so use a small library or this page.

No. Everything, including reading PDF files, is worked out in your browser, and nothing is uploaded by this tool. Large inputs aren't saved either.