Introduction
Z85 is the Base85 variant that ZeroMQ uses to encode 4-byte binary chunks into 5 ASCII characters. If you work with CURVE keys, ZeroMQ sockets, or any system that adopted ZeroMQ RFC 32, you have seen Z85 strings. This tool encodes text to Z85 and decodes it back in your browser. Paste your input, pick the mode, and the result appears instantly. No data is sent anywhere.
What this tool does
- Encodes UTF-8 text into Z85 using the 85-character ASCII alphabet defined in ZeroMQ RFC 32.
- Decodes Z85 back to the original UTF-8 text, rejecting characters outside the alphabet.
- Enforces the 4-byte input multiple on encode and the 5-character multiple on decode, matching the spec.
- Strips whitespace on decode so pasted output with line breaks still parses.
- Processes everything client-side with no server calls.
How this tool works
The encoder converts your input to UTF-8 bytes and requires the length to be a multiple of 4, because Z85 maps each 4-byte group to 5 characters. It interprets the group as a big-endian 32-bit integer, then divides by 85 five times, mapping each remainder to the Z85 alphabet to produce five characters. Decoding reverses this: each 5-character group is converted back to a 32-bit integer and split into four bytes.
If the input length is not a multiple of 4 on encode, or not a multiple of 5 on decode, the tool reports a clear error rather than silently truncating. This matches the ZeroMQ specification, which does not define padding. On decode, whitespace is stripped first so wrapped output still parses.
How Z85 works
Z85 is defined in ZeroMQ RFC 32, which specifies a different 85-character alphabet from Ascii85. The Z85 alphabet is `0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-:+=^!/*?&<>()[]{}@%$#`. The order matters: it is not the same as Ascii85, and the two are not interchangeable.
The encoding ratio is 5 characters for every 4 bytes, so the output is 25% larger than the input in characters. That is more efficient than Base64, which expands by 33%. The trade-off is the strict alignment requirement: Z85 has no padding scheme, so the input must already be a multiple of 4 bytes. ZeroMQ uses Z85 to encode 32-byte CURVE public and secret keys as 40-character strings, which is the most common place developers encounter it.
Z85 differs from Base85 and Ascii85 in alphabet and in handling of the final group. Ascii85 (used in PDF and PostScript) supports a special `z` shorthand for all-zero groups and a `y` shorthand for all-space groups, and it has a partial-group padding scheme. Z85 has neither. The two formats solve the same problem for different ecosystems.
How to use this tool
- Type or paste your text into the input field.
- Keep the mode on Encode to produce Z85, or switch to Decode to recover the original text.
- For encoding, make sure the UTF-8 byte length is a multiple of 4, otherwise the tool reports an error.
- For decoding, paste Z85 text. Whitespace is ignored; the length must be a multiple of 5 characters.
- Use Swap to feed the output back as input and flip the mode in one click.
Real-world examples
Encoding a ZeroMQ CURVE public key
A ZeroMQ application generates a 32-byte Curve25519 public key. The library hands back raw bytes, but the configuration file expects a 40-character Z85 string. Encoding the 32 bytes with this tool produces the 40-character string that `zmq_curve_public` expects. The team pastes it into their config and the socket connects.
Decoding a Z85 key for debugging
A developer finds a 40-character Z85 string in a log file and needs the raw bytes to compare against a known key. They paste the string into the decoder, recover the 32 bytes, and hex-dump them. Because Z85 has no padding, the 40-character length maps cleanly to 32 bytes with no ambiguity.
Handling a non-aligned input
Someone tries to encode a 13-byte payload. The tool reports that the input must be a multiple of 4 bytes. They pad the payload to 16 bytes on their side, encode it, and note that the receiver must trim the 3 padding bytes after decoding. This is the expected Z85 workflow since the spec defines no padding.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Base64 | 6 bits/char, padded | Email, JWTs (RFC 4648) |
| Ascii85 | ~6.4 bits/char, padded | PDF, PostScript |
| Base85 (RFC 1924) | ~6.4 bits/char | IPv6 addresses |
| Z85 | 6.4 bits/char, no padding | ZeroMQ CURVE keys (RFC 32) |
Limitations or considerations
Z85 is an encoding, not encryption. It provides no confidentiality. The strict 4-byte alignment with no padding means you must handle padding yourself for arbitrary-length payloads, which is the main reason it is used for fixed-size keys rather than general data. The Z85 alphabet is incompatible with Ascii85 and RFC 1924 Base85, so a string from one will not decode in another. Do not use Z85 to protect sensitive data.
Frequently asked questions
What is the difference between Z85 and Ascii85?
They use different 85-character alphabets and different end-of-data handling. Ascii85 supports `z` and `y` shorthands and a partial-group padding scheme. Z85 has neither and uses the alphabet defined in ZeroMQ RFC 32. The two are not interchangeable.
Why does Z85 require the input to be a multiple of 4 bytes?
The spec maps 4-byte groups to 5-character groups and defines no padding. ZeroMQ uses it for fixed 32-byte keys, which are always a multiple of 4, so padding was unnecessary. For variable-length data you must pad before encoding and trim after decoding.
Can I use Z85 for IPv6 addresses?
IPv6 addresses use the Base85 variant from RFC 1924, which has a different alphabet. Z85 is the ZeroMQ variant. They are not the same, so use the matching encoder for your use case.
Is Z85 URL-safe?
The Z85 alphabet includes characters like `<`, `>`, `(`, `)`, and `#` that are not URL-safe and would need percent-encoding. For URL-safe output, Base64 with URL-safe alphabet is a better fit.
Conclusion
Z85 is the right encoding when you are working with ZeroMQ CURVE keys or any system that adopted RFC 32. It is denser than Base64 and uses a distinct 85-character alphabet with no padding. Encode a 32-byte key above to see the 40-character output ZeroMQ expects. For PDF-style Ascii85 or RFC 1924 IPv6 encoding, switch to the Base85 or Ascii85 tools.