Encode text or files into Ascii85 / Base85 with three honest variants: Adobe Ascii85 (PostScript & PDF, with the z zero shortcut and <~ ~> delimiters), RFC 1924 Base85 (IPv6 text form), and ZeroMQ Z85 (binary frames & CURVE keys). Compare their alphabets side by side, wrap long lines, and inspect exact size stats. 100% client-side — your data never leaves this device.
Encoder
Input size
–
Output size
–
Expansion ratio
–
Overhead vs raw
–
Alphabet of the active variant
The three variants compared
Adobe Ascii85
RFC 1924 Base85
Z85 (ZeroMQ)
Alphabet
! (33) to u (117)
0-9 A-Z a-z then !#$%&()*+-;<=>?@^_`{|}~
0-9 a-z A-Z then .-:+=^!/*?&<>()[]{}@%$#
Zero shortcut
z for 4 zero bytes (optional)
none
none
Framing
<~ ~> (optional)
none
none
Short final group
zero-padded, truncated to n+1 chars
zero-padded (count reported)
zero-padded (count reported)
Typical use
PostScript, PDF streams
IPv6 text representation (RFC 1924)
ZeroMQ CURVE keys, binary frames
Same 8 bytes →
L/669[9<6.
hELLOwORLD
HelloWorld
* The same byte values land on different characters in each alphabet — the three outputs are not interchangeable. Bytes 86 4F D2 6F B5 59 F7 5B encode as HelloWorld in Z85 (the ZeroMQ spec test vector) but as hELLOwORLD in RFC 1924: identical digit values, different character assignment.
Worked example
The classic example from Adobe's PostScript specification: the 4 bytes of Man (4D 61 6E 20) form the 32-bit value 1,298,230,816, whose five base-85 digits are 24, 73, 80, 78, 61 — characters 9 j q o ^:
Man → 9jqo^ <~9jqo^~> (with Adobe delimiters) 00 00 00 00 → z (the zero shortcut)
Frequently asked questions
What is Ascii85 encoding and how does it work?
Ascii85 (also called Base85) packs 4 binary bytes into 5 printable ASCII characters: each 4-byte group is read as one 32-bit number and written out as 5 base-85 digits. That is only 25% size overhead, versus about 33% for Base64. Adobe adopted it for PostScript and PDF streams, where large embedded images and fonts made the 8% saving worthwhile. This encoder also supports the RFC 1924 and Z85 flavors of the same idea.
What is the difference between Adobe Ascii85, RFC 1924 Base85, and Z85?
All three encode 4 bytes as 5 characters, but each uses a different 85-character alphabet, so their outputs are NOT interchangeable. Adobe Ascii85 uses characters from ! (33) to u (117), adds the z shortcut for four zero bytes, and wraps output in <~ ~> delimiters. RFC 1924 Base85 (used for IPv6 text form) uses 0-9A-Za-z plus punctuation. ZeroMQ Z85 puts lowercase before uppercase and is designed for keys and binary frames. Try it: the same 8 bytes encode as HelloWorld in Z85 but hELLOwORLD in RFC 1924.
What does the z shortcut in Ascii85 mean?
In Adobe Ascii85, the single character z is shorthand for four zero bytes, which would otherwise encode as !!!!!. It is an Adobe extension, not part of the original btoa format, so decoders that do not know it will reject the output - this tool lets you turn it off. Note that z is only ever used for complete 4-byte groups of zeros, never for a short final group: two zero bytes at the end of the input still encode as regular characters.
Why do RFC 1924 and Z85 require the input length to be a multiple of 4?
Both specifications define encoding strictly over 4-byte frames: RFC 1924 always encodes full IPv6 addresses (16 bytes) and ZeroMQ Z85 encodes binary frames whose size is divisible by 4. There is no padding rule in either spec. When your input is not a multiple of 4, this tool zero-pads the final group (like Python's base64.b85encode with pad=True) and tells you exactly how many zero bytes were added, so the result stays reproducible and the padding is never silent.
Is Ascii85 better than Base64?
For size, yes: Ascii85 adds 25% overhead versus about 33% for Base64, so a 1 MB file becomes roughly 1.25 MB instead of 1.33 MB. The price is compatibility. Base64 output is alphanumeric plus two symbols and is understood by virtually every language and API, while the Ascii85 alphabet is full of punctuation like quotes, angle brackets, and ampersands that need escaping in URLs, shells, and JSON. Use Ascii85 when you control both ends and size matters (PDF and PostScript internals do exactly this); use Base64 everywhere else.
How do I decode Ascii85 or Z85 output back to the original data?
Use the companion Base85 decoder, which accepts all three variants produced here: paste the output, pick Adobe Ascii85, RFC 1924, or Z85, and it reconstructs the original bytes as UTF-8 text, a hex dump, or a downloadable file. Adobe delimiters (<~ ~>) and whitespace are stripped automatically, and the z shortcut is expanded back to four zero bytes.
Is my data uploaded to a server when I encode a file?
No. This tool is 100% client-side: the encoding runs entirely in your browser with JavaScript, and neither your text nor your uploaded file ever leaves your device. There are no network requests, no third-party scripts, and no tracking of what you encode, which is why it is safe to use for sensitive keys, tokens, or document internals.
Related tools:Base85 Decoder — decode Adobe Ascii85, RFC 1924, or Z85 back to text, hex, or a file ·
Base64 Encoder — compare against the 33%-overhead classic
We use cookies and third-party services (including Google AdSense) to personalize content, analyze traffic, and serve relevant ads. By clicking "Accept", you consent to our use of cookies as described in our Privacy Policy.
Report an issue
2 taps, no typing needed — diagnostics are sent automatically.