> encode | decode | ascii85 <

Base85, also known as ASCII85, is a binary-to-text encoding scheme that uses 85 printable ASCII characters to represent binary data more efficiently than Base64.

Base85 encodes 4 bytes as 5 characters (80% efficiency) while Base64 encodes 3 bytes as 4 characters (75% efficiency), making Base85 about 25% more space-efficient.

The <~ and ~> delimiters are part of the Adobe ASCII85 standard, marking the beginning and end of encoded data. They help identify Base85 content in documents.

The 'z' character is a special shortcut in ASCII85 that represents four consecutive zero bytes (\x00\x00\x00\x00), making the encoding more efficient.

All three share the same 85-symbol core math but differ in alphabet and context:
• ASCII85 (Adobe) — used in PostScript and PDF. Uses !-u plus z as the all-zeros shortcut. Wrapped in <~ ... ~> delimiters.
• ASCII85 (btoa) — an older 1990s Unix utility variant. Slightly different delimiters (xbtoa Begin / xbtoa End) and a checksum.
• Z85 (ZeroMQ / RFC 32) — uses a URL- and shell-safe subset: avoids ", ', \, ,, ;, :. Designed for ZeroMQ CURVE keys and config files. No delimiters, no z shortcut.
• RFC 1924 (IPv6) — 85-character alphabet proposed for IPv6 addresses on April 1, 1996 — never adopted.
Our tool targets Adobe ASCII85 by default; other variants require matching alphabet and padding rules.

A:
Python: built-in — import base64; base64.a85encode(b'Hello') → b'87cURD]i', base64.a85decode(s). For Adobe variant with delimiters: a85encode(b'Hello', adobe=True).
Node.js: no stdlib support — use npm i ascii85: require('ascii85').encode('Hello').
Go: encoding/ascii85 — ascii85.Encode(dst, src), but no Adobe wrappers (you add them manually).
Java: third-party like com.google.zxing.common or Bouncy Castle.
PostScript / PDF: use the /ASCII85Decode filter.
All produce the same core output for Hello: 87cURD]i.

把 Base85（ASCII85） 字符串贴入左侧输入框即可。如果包含 Adobe 的 <~ ~> 定界符，工具会自动识别并剥离；否则会按纯 ASCII85 解析。点击 [DECODE]，还原的二进制（或 UTF-8 文本）出现在右侧。
Base85 在线编码 同理：输入文本或粘贴二进制（Hex/Base64 预转换），点击 [ENCODE] 得到带定界符的 ASCII85 串。
常见场景：
• PDF / PostScript 流内嵌二进制
• Git binary patch（使用 ASCII85 变体）
• ZeroMQ CURVE 密钥（Z85 变体）
所有解码在浏览器中完成，私钥或 PDF 片段不会上传。

For every 4 bytes of input:
• Base64: produces 4 × 4/3 ≈ 5.33 chars (rounded up to 6 with padding).
• Base85: produces exactly 5 chars.
That's a 25% size reduction over Base64 — or put differently, Base85 adds only 25% overhead to raw binary, while Base64 adds 33%. The reason PDF chose ASCII85 in the late 1980s was precisely this: PDF files embed large binary streams, and saving 25% per embedded image across every document mattered for dial-up-era distribution. Today Base85 is less common online because Base64 is built into every language and every tool.

No — not the Adobe variant. ASCII85 includes &, ,, ;, ', ", <, and >, all of which require URL encoding or shell escaping. For URL-safe contexts, use:
1. Base64url (the standard choice — no padding, URL-safe alphabet).
2. Z85 / RFC 32 — Base85 with a curated alphabet that avoids shell and URL special characters.
3. Base62 — strictly alphanumeric, slightly larger than Base85.
For internal storage, signatures, or PDF/PostScript, Adobe Base85 is fine; for query strings or JSON field values, use Base64url instead.

Some tools (older btoa, custom PostScript pipelines, Z85, Git) emit Base85 without the Adobe <~ ... ~> wrapper. You have two options:
1. Paste the raw string into our decoder — it accepts both wrapped and unwrapped input. Non-alphanumeric characters outside the 85-symbol range are treated as errors, not delimiters.
2. Manually wrap it: prepend <~ and append ~> before pasting, which forces Adobe-mode decoding.
If decoding fails with "invalid character," your input is probably Z85 (ZeroMQ variant) — the alphabet differs and you need a Z85-specific decoder.