Overview
Encodes text or binary data as Ascii85 (Base85) and decodes it back, byte-exact. Ascii85 packs every 4 bytes into 5 printable characters - 25% overhead instead of Base64's 33% - and compresses a run of four zero bytes to a single 'z'. It is the binary encoding used inside PDF and PostScript files and by git binary patches, and the Adobe <~ ~> delimiters are handled automatically.
How It Works
Choose Encode or Decode. Encoding takes any text (UTF-8 encoded first) and produces the Ascii85 string. Decoding takes Ascii85 - with or without the Adobe <~ ~> framing, with or without whitespace - and returns the original bytes as text. Invalid characters, corrupt groups that overflow 32 bits, and misplaced 'z' markers produce a specific error message instead of garbage output.
Step-by-Step Usage Guide
- Pick Encode to turn text into Ascii85, or Decode to recover the original.
- For decoding, paste the string as-is - <~ ~> framing and line breaks are stripped for you.
- Copy the output from either panel.
- If decoding fails, read the error: it names the offending character or the corrupt group.
Technical Specifications & Standards
The algorithm treats each 4-byte group as a big-endian 32-bit number and writes it as five base-85 digits over the printable range from '!' (33) to 'u' (117). A partial group at the end is padded with zeros and encoded to k+1 characters for k remaining bytes, which is what makes the decode self-delimiting: the decoder pads a short group with 'u' (the maximum digit) and keeps only k bytes. The special digit 'z' stands for four zero bytes and is only legal between groups - accepting it inside a group would make some encodings ambiguous, so the decoder rejects it there. The overflow check matters in practice: five characters can represent values above 2^32, and only values below it are valid encodings, so a single mistyped character is caught instead of silently corrupting a PDF stream or a git patch. This implementation uses the standard btoa/Adobe variant; the RFC 1924 alphabet used by IPv6 literals is a different, order-shuffled alphabet and is intentionally not accepted.
Targeted Use Cases
- Reading or editing the binary streams inside PDF files, where images and fonts are embedded as Ascii85.
- Working with git binary patches, which use Ascii85 for their data hunks.
- Squeezing binary data into a context that only allows printable ASCII, with less overhead than Base64.
- Understanding PostScript or EPS files that embed data in <~ ~> blocks.
Notes & Gotchas
- Do not confuse Ascii85 variants: this is the Adobe/btoa alphabet; ZeroMQ's Z85 and RFC 1924 use different alphabets.
- Decode before editing and re-encode after: editing the Ascii85 text directly almost always corrupts the underlying bytes.
- For long data, remember 'z' only appears for complete zero groups - a 'z' inside a group means the input is corrupt.
- The output includes quote and backslash characters; when embedding in source code, escape them for your host language.
Frequently Asked Questions
Why use Ascii85 instead of Base64?
Efficiency: 4 bytes become 5 characters (25% overhead) versus Base64's 3-to-4 (33% overhead), and four zero bytes become a single character. It also has no padding. The trade is a larger, less URL-safe alphabet.
What are the <~ and ~> marks?
The Adobe delimiters from PostScript and PDF. They are not part of the encoded data; this tool strips them on decode and does not add them on encode, so the output is the bare payload.
Why did decoding fail on what looks like valid input?
Either a character is outside the 85-character alphabet, a 5-character group encodes a value above 2^32 (one mistyped character does this), or a 'z' appears inside a group. The error message says which.
How does it handle Unicode text?
Encoding converts the text to UTF-8 bytes first, so any text encodes; decoding produces UTF-8 bytes interpreted as text. Binary data that is not valid UTF-8 should stay binary - this page renders the decoded bytes as text, so non-UTF-8 payloads will show replacement characters.