Base85 Encoder / Decoder

Encode and decode ASCII85 (Adobe Base85) with <~ ~> delimiters.

Text to encode

About Base85 / ASCII85 encoding

Base85 (ASCII85) encodes binary data using 85 printable ASCII characters (codes 33–117), producing output that is ~25% shorter than Base64. Every 4 bytes of input map to 5 output characters. The Adobe/PostScript variant wraps the data in <~ and ~> delimiters and uses a special "z" shorthand for four zero bytes. It is used in PDF streams and PostScript files.

For Base64 encoding, see the Base64 Encoder / Decoder.

Built and maintained by Meet Shah · Last updated 25 July 2026

What this tool is used for

Decoding an ASCII85 stream out of a PDF or a PostScript file while inspecting it.
Encoding binary data more compactly than Base64 for a text-only channel.
Producing a Base85 fixture for code that has to parse it.
Comparing encoding overhead against Base64 for a size-sensitive payload.
Understanding a legacy format when maintaining a parser.

Frequently Asked Questions

Why Base85 rather than Base64?: Density. Four bytes become five characters — 25% overhead against Base64's 33%. It achieves this by using 85 symbols, since 85^5 is just above 2^32, which is the smallest base that fits four bytes in five characters.
Which variant am I using?: It matters, because they are incompatible. Ascii85 (Adobe, used in PostScript and PDF) starts its alphabet at ! and wraps in <~ ~>; Z85 (ZeroMQ) uses a different alphabet chosen to be safe in source code strings.
What is the z shortcut?: In Ascii85, four zero bytes encode as the single character z instead of !!!!!. It is a genuine compression win for padded binary, and a decoder that does not implement it fails on real PDF streams.
Why is it not more widely used?: Because its alphabet includes quotes, backslashes and angle brackets, which need escaping in JSON, XML and most source code — wiping out the density advantage. Base64's alphabet is deliberately duller and therefore safer.
Where will I actually meet it?: Inside PDF files (ASCII85Decode filters), PostScript, git binary patches, and ZeroMQ keys. It is a niche format you decode more often than you produce.
How much smaller is it than base64?: About 7% — four bytes become five characters rather than three becoming four, so the overhead falls from 33% to 25%. That modest gain is why base64 remains the default despite being less efficient.
Why is Adobe's variant incompatible with the RFC 1924 one?: Different alphabets and different framing. Adobe's ASCII85 uses `<~` and `~>` delimiters and a `z` shortcut for four zero bytes; the RFC variant uses a different character set entirely, so a decoder must know which it is reading.
Is the output safe to embed in source code?: Not without care — the standard alphabet includes quotes, backslashes and other characters that need escaping in most languages. That is another reason base64 wins for embedding.

Common errors and gotchas

Assuming one Base85. The ASCII85, Z85 and RFC 1924 variants use different alphabets and are not interchangeable.
Overlooking the `<~` and `~>` delimiters that ASCII85 streams use, which are not part of the data.
Missing the `z` shorthand for four zero bytes, which a naive decoder mishandles.
Expecting URL safety. The alphabet includes characters that must be percent-encoded.
Ignoring whitespace rules, where line breaks are permitted in some variants and significant in none.