Z85 is the Base85 variant defined in ZeroMQ RFC 32. It packs four bytes into five characters like Ascii85, but its 85-character alphabet is chosen so the output is safe to paste straight into source-code string literals — no backslash, quote, or other escape-prone symbols. This tool encodes UTF-8 text into Z85 and decodes it back, all in your browser.
How it works
Z85 treats the data as a stream of four-byte groups:
- Each group of four bytes forms a 32-bit number.
- That number is expressed as five base-85 digits, each mapped through the alphabet
0-9 a-z A-Zfollowed by the punctuation set.-:+=^!/*?&<>()[]{}@%$#, written most-significant first. - Decoding reverses this: every five characters rebuild a 32-bit value, which is split back into four bytes.
Because Z85 has no padding, the byte length must be a multiple of four. When you encode free text, the tool adds the minimum number of zero bytes to reach a four-byte boundary and reports how many it appended.
Why Z85 over Base64 or Ascii85?
The question that comes up every time someone encounters Z85 is: why not just use Base64?
Compactness. Base64 encodes three bytes as four characters — a 33% size overhead. Base85 (including Z85) encodes four bytes as five characters — a 25% overhead. For configurations that store many binary keys or hashes, Z85 produces meaningfully shorter strings than Base64.
Source-code safety. Base64 uses + and /, which need escaping in many contexts (URLs, JSON strings without care, shell arguments). Ascii85 uses characters like backslash and single-quote that also need escaping inside string literals in most languages. Z85’s alphabet was designed specifically to require no escaping inside C, Python, JavaScript, or JSON string literals, which is its key differentiator.
ZeroMQ ecosystem fit. CurveZMQ — the public-key encryption layer used in ZeroMQ — uses 32-byte keys. Z85 encodes those keys into exactly 40-character strings that can be pasted directly into configuration files and C string initializers without any wrapping or escaping. This was the primary design goal of RFC 32.
Alphabet comparison
| Encoding | Overhead | Special chars requiring escaping in string literals |
|---|---|---|
| Base64 | 33% | +, /, = |
| Ascii85 | 25% | \, ', ", and others |
| Z85 | 25% | None (alphabet chosen to avoid them) |
Tips and example
The canonical RFC 32 test vector — the bytes 86 4F D2 6F B5 59 F7 5B — encodes to HelloWorld, a neat demonstration of the format. Z85 shines for fixed-length binary such as the 32-byte CurveZMQ keys ZeroMQ uses, which become a tidy 40-character string.
If your data already aligns to four bytes, no padding is needed and the round-trip is exact. If it does not, the encoded output includes the padding bytes — remember to strip them after decoding if you only wanted the original length. The tool tells you how many padding bytes were added so you know how many to remove.