How to use the Base85 Decoder
Decode a Base85 string in three steps:
1
Paste the Base85 string
Paste any Ascii85 or Base85 string, with or without <~ ~> delimiters. Delimiters and whitespace are stripped automatically.
2
Select the variant
Choose Ascii85 (PostScript/PDF/Git, uses ! to u alphabet, supports z for null groups) or RFC 1924 (Python b85/Z85, different alphabet). The wrong variant will produce garbled output.
3
Copy the decoded output
The original text appears. An error is shown for invalid characters or malformed groups. Copy or download.
When to use this tool
Use Base85 decoding to recover original content from Ascii85-encoded sources:
- →Decoding Ascii85-encoded streams extracted from PostScript or PDF documents to inspect binary content
- →Recovering the original binary data from a Git binary patch that uses Base85 encoding for diff output
- →Decoding Base85-encoded data produced by Python's binascii.b2a_base85() for debugging or inspection
- →Inspecting Base85-encoded frames from ZeroMQ (Z85 encoding) for protocol-level debugging
- →Verifying that a Base85 encoding round-trip (encode then decode) produces the original input correctly
- →Decoding RFC 1924 Base85-encoded IPv6 addresses or other protocol fields that use this variant
Frequently asked questions
Q:Why does Base85 decoding produce garbled output?
Garbled output almost always means the wrong variant was selected. Ascii85 and RFC 1924 Base85 use completely different character alphabets — a string encoded with one variant cannot be decoded correctly with the other. Try switching the variant selector. Other causes include: truncated input (missing characters from the last group), or the data being binary content rather than UTF-8 text — binary data decoded as UTF-8 will appear garbled.
Q:What does the z in Ascii85 encoded strings mean?
In Ascii85, the single character z is a special abbreviation for a group of four null bytes (0x00000000). When decoding, every z in the stream expands to 5 characters of decoded output representing four zero bytes. This is why Ascii85 strings may appear shorter than expected — null byte runs are compressed to single characters. The RFC 1924 variant does not use this abbreviation.
Q:Do I need to include the <~ ~> delimiters when decoding?
No — the <~ and ~> delimiters are optional for decoding. The tool automatically detects and strips them if present, so you can paste Ascii85 with or without them. If your string starts with <~ and ends with ~>, they will be removed before decoding begins. The delimiters are informational markers, not part of the encoded data itself.
Q:What characters are valid in Ascii85?
Valid Ascii85 characters are printable ASCII characters from ! (code 33) to u (code 117) — 85 characters total. Additionally, z is valid as a null-group abbreviation, and ~ immediately followed by > is valid as the end delimiter. Whitespace (spaces, tabs, newlines) is ignored during decoding. Any other character produces a decode error.
Q:Can I decode Python's base64.b85decode() output?
Python's base64.b85encode() and b85decode() use a variant of RFC 1924 Base85, not Ascii85. Select the 'RFC 1924' variant in the tool to decode Python Base85 output correctly. Python also has binascii.b2a_base85() which uses Ascii85; for that, select the 'Ascii85' variant.
Q:Is there a size limit for decoding?
No enforced size limit. Base85 decoding processes 5 characters at a time to produce 4 bytes, so decoding is O(n) and handles large strings efficiently. All processing runs in your browser with no server involvement. Very large decoded outputs (megabytes of text) may be slow to render in the output text area — use the download option for large payloads.