Encode and decode data using Base85 (Ascii85, Z85, or RFC 1924) encoding variants.
This tool takes bytes (typed text or a pasted string) and encodes them into one of three Base85 dialects, or reverses the process. Ascii85 and Z85 both work by treating each 4-byte group as a big-endian 32-bit number and re-expressing it in base 85 as 5 characters. RFC 1924 was originally defined to encode a whole 128-bit IPv6 address as a single 20-digit base-85 number, not as a general 4-byte-block codec, so this tool's block-wise application of the RFC 1924 alphabet to 4-byte groups is an adaptation rather than something the RFC itself specifies. Each variant also uses a different 85-character alphabet and different rules for a final partial group. The mistake people make most often is decoding output with the wrong variant selected - if the wrong alphabet happens to contain all the characters in the input and the length is otherwise valid, decoding silently returns wrong bytes; only when the input has characters outside that alphabet or violates its length rules does the wrong-variant decode fail with an error.
A concrete input and expected output from the current implementation.
Input
Man (Ascii85 encode, 4 ASCII bytes: M a n and a trailing space)
Expected output
9jqo^
The 4 bytes 0x4D 0x61 0x6E 0x20 form the 32-bit value 1,298,230,816, which in base 85 is digits 24,73,80,78,61; adding Ascii85's offset of 33 to each gives the characters 9, j, q, o, ^ - this is the standard worked example from Adobe's own Ascii85 documentation.
Input is split into 4-byte groups, each read as an unsigned 32-bit big-endian integer, then converted to base 85 and written as 5 characters using the selected variant's alphabet. Ascii85 additionally shortcuts an all-zero 4-byte group to a single 'z' character on encode, which this tool expands back on decode.
Ascii85 uses ASCII 33-117 ('!' through 'u'); Z85 uses an 85-character set of digits, letters, and symbols chosen to avoid characters that need escaping in C string literals and other structured text; RFC 1924 uses its own ordering aimed at IPv6 literals. Ascii85 has a defined rule for a final partial group (it is padded with zero bytes before encoding, and the corresponding extra output characters are trimmed). Standard Z85 requires the input length to be a multiple of 4 bytes and defines no partial-group rule, and RFC 1924 likewise defines no general partial-block padding rule, so any partial-group handling this tool applies for Z85 or RFC 1924 input is a tool-specific extension, not a rule of those variants.
Yes - Base85 has about 25% size overhead versus Base64's roughly 33%, since it packs 4 bytes into 5 characters instead of 3 bytes into 4. It is not a universal win though: standard Base64's alphabet includes '+' and '/', which are not URL- or filename-safe without switching to the separate Base64url variant, and Z85's alphabet also includes URL-significant characters such as '/', '?', '&', '%', and '#' - Z85 was designed for convenient embedding in source code and structured text, not specifically for URL or filename safety.
Usually, but strip the optional Adobe delimiters '<~' and '~>' first if present, and remove any line breaks or whitespace the PDF inserted for line length - Ascii85 ignores whitespace between characters in principle, but this tool expects a clean run of valid alphabet characters for a reliable decode.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Convert CSV data into structured JSON arrays or objects with automatic type detection.
Transform JSON arrays and objects into downloadable CSV spreadsheet format.
Convert YAML configuration files to JSON format with validation and formatting.
Parse XML documents and convert them to equivalent JSON structure with attributes.
Convert tab-separated values to comma-separated format with proper escaping.
Convert numbers between binary, octal, decimal, and hexadecimal bases.