Base85 encoder: three variants, side by side

What is base85?

Base85 packs binary data into printable text using 85 different characters. Four bytes become five characters, which is why it exists: base64 turns three bytes into four, a 33% expansion, while base85 manages 25%. That saving is why PostScript and PDF adopted it, and why it still turns up wherever binary has to survive a text channel.

The catch is that base85 is not one format. At least three things go by the name and none of them can read another's output. Ascii85 uses the 85 characters starting at the exclamation mark and is what PostScript, PDF and the original btoa produce. Z85, specified by ZeroMQ, uses a deliberately different alphabet chosen so the output is safe to paste into source code. And a third variant, the one most programming libraries mean, uses the alphabet from RFC 1924.

This page encodes your bytes under all three at once, so the differences are visible rather than theoretical, and it can take a string in the other direction to show you what each variant thinks it means.

How to use it

1. Give it some bytes. As hex or as text, whichever suits. The samples cover the ZeroMQ specification's own test vector, a run of zero bytes, and a single byte, each of which behaves differently across the three variants.
2. Compare the three outputs. They are shown together, with a note on what each variant is. Ascii85 has two options worth trying: the Adobe delimiters, and the shorthand that writes four zero bytes as a single z.
3. Or switch to reading a string. Paste base85 text and every variant that can decode it will, with the bytes each one produces. Where two disagree, the string itself cannot tell you which is right.

Why swapping variants is dangerous

A base85 string carries no marker saying which variant produced it. Feed one to the wrong decoder and one of two things happens: it rejects the input, or it succeeds and hands back different bytes with no complaint at all.

Measured over five thousand random inputs, decoding Ascii85 output with the RFC 1924 alphabet returns wrong bytes without error about 16% of the time and throws the rest. The reverse direction behaves the same way, at 16.6%. So roughly one time in six you get plausible rubbish rather than a message telling you something went wrong.

That is the reverse of what this site found for base58, where the two competing alphabets contain the identical 58 characters in a different order. There, a swap always decodes silently, because every character valid in one alphabet is valid in the other. Base85's variants use genuinely different character sets, so most of the time the mismatch produces an error. The five times out of six that it fails loudly are the format protecting you; the remaining one is why the variant has to be recorded somewhere other than in the string.

Z85 is the strictest of the three and the least likely to accept something it should not. Its specification requires the binary length to be divisible by four and the text length by five, and defines no padding at all, leaving that to the caller. So it simply refuses input the other two would pad, which is why one of the samples here encodes under Ascii85 and the RFC 1924 alphabet and is turned away by Z85.

The variant that is not what its name says

The third variant is generally called RFC 1924 base85, and that name is misleading. RFC 1924 is about IPv6 addresses. Its encoding section says to treat an address as a single 128-bit integer, write that integer in base 85, and render it with 85 ASCII characters, giving exactly twenty digits. It describes no way to encode a stream of bytes, and nowhere in the document is there any mention of processing four bytes at a time.

What libraries actually implement under that name is the RFC's alphabet with Ascii85's four-byte grouping applied to it. That is a perfectly reasonable thing to build, and it is not what the RFC specifies. The third mode on this page implements the RFC's actual algorithm, so you can encode a real address and get the twenty digits the document describes.

The RFC is also worth reading for its own sake. It is dated 1 April 1996, is categorised as Informational, and states in its opening lines that it does not specify an Internet standard of any kind. Its section on why 85 was chosen works through base 84 and base 94 before settling, and it explains the character set as having been selected with considerable care to leave punctuation free for delimiting addresses. Draw your own conclusions about the date.

What this cannot tell you

It cannot tell you which variant produced a string you were given. That is the whole problem: nothing in the encoding records it. If a string decodes cleanly under two variants, both answers are shown and the choice is yours, informed by where the string came from rather than by anything in it.

The three variants here are the ones in wide use, not all of them. Ascii85 in particular has dialects: the btoa program had a shorthand for four spaces as well as for four zero bytes, and some tools wrap output at a fixed column while others do not. Those are variations within Ascii85 rather than separate formats, but they are enough to make two Ascii85 implementations disagree on the exact text.

And base85 is a poor fit for anywhere the output has to survive a URL, a filename or a shell command. Every variant uses punctuation heavily, and the characters differ between them, so text that is safe in one context may need escaping in another. That is the problem Z85 was designed around, and it is why its alphabet excludes the quotes and backslashes that would otherwise need escaping inside a string literal.

Why is it free?

Base conversion is arithmetic, and it runs in your browser. There is no server in the loop, so there is nothing to bill for and no account to create.

Nothing is uploaded. The bytes you paste never leave the tab.