Ascii85 (also written Base85 or a85) is the binary-to-text encoding used in PDF and PostScript streams. By mapping four bytes onto five printable characters it is noticeably denser than Base64, which makes embedded images and fonts smaller. This tool encodes UTF-8 text into Ascii85 and decodes it back, including the z shortcut and optional PDF framing, all in your browser.
How it works
Ascii85 works on four-byte groups using base 85 with an offset:
- Four bytes form a 32-bit number. That number is written as five base-85 digits, each offset by 33 so the characters fall in the printable range starting at
!. - A full group of four zero bytes is collapsed to the single character
zto save space. - A partial final group is padded with zero bytes to length four, encoded, then truncated so it emits exactly one more character than the number of real bytes.
Decoding reverses each step: every five characters rebuild a 32-bit value and therefore four bytes, z expands to four zero bytes, and a short final group is padded with the highest digit u before the surplus byte is dropped. Optional <~ and ~> delimiters are stripped automatically.
Worked example and practical notes
Encoding the four bytes of Man yields 9jqo^, the classic Ascii85 example. A run of zero bytes — common in binary headers and image data — compresses dramatically thanks to the z shortcut: four zero bytes that would otherwise take five characters collapse to just one z.
When you copy a stream out of a PDF, it usually carries the <~ ... ~> framing. Paste it as-is and the decoder strips the delimiters automatically. If the data came from a PostScript file instead, the same framing conventions apply.
Ascii85 in PDF and PostScript
Inside a PDF file, binary objects — images, fonts, compressed streams — are embedded as ASCII text using one of several filters. Ascii85Decode is among the most common, alongside Flate (zlib) compression. If you inspect a PDF’s raw bytes in a hex editor, you may see streams that begin <~ and end ~> with the encoded content between them. Extracting that block and decoding it with this tool reveals the compressed or raw binary inside.
The reason PDF uses Ascii85 rather than Base64 is historical: PostScript, which predates PDF, needed streams that could pass through systems designed for human-readable PS code. Ascii85’s smaller alphabet (33–117, all printable) and good density made it the practical choice in the Adobe ecosystem.
Ascii85 versus Base64 and Base85/Z85
| Encoding | Overhead vs binary | Use case |
|---|---|---|
| Base64 | ~33% | Email, data URIs, APIs |
| Ascii85 (Adobe) | ~25% | PDF, PostScript streams |
| Z85 (ZeroMQ) | ~25% | Source-code embedded strings |
Ascii85 and Z85 share the same size efficiency — about 25% overhead — but use different character sets. Ascii85 uses characters 33–117; Z85 uses an alphanumeric-and-punctuation set deliberately chosen to be safe inside C and JSON string literals without escaping. Never mix the two: an Ascii85-encoded string decoded with Z85 logic produces wrong bytes.
Note that Ascii85 is the Adobe variant; for the ZeroMQ-flavoured Base85 that is safe inside source-code string literals, use the dedicated Z85 tool instead. All encoding and decoding here runs entirely in your browser.