About

Base64 inflates binary data by approximately 33% because it maps every 3 bytes to 4 ASCII characters using a 64-symbol alphabet. Ascii85 (also called Base85 or btoa encoding) reduces that overhead to roughly 25% by encoding 4 bytes into 5 characters drawn from a 85-character range (! through u, ASCII codes 33 - 117). The format was adopted by Adobe PostScript and PDF internals, where every kilobyte of payload size matters for render performance. This tool performs real byte-level conversion between the two encodings. It does not transliterate strings; it decodes one encoding to its raw binary form and re-encodes it in the target format. Malformed input - wrong character sets, broken padding, or missing <~~> delimiters - will produce a specific validation error rather than silent corruption.

Formulas

Ascii85 encodes a group of 4 bytes into 5 printable ASCII characters. The 4 bytes are treated as a big-endian 32-bit unsigned integer N, then decomposed by successive division by 85:

N = b₀ ⋅ 256³ + b₁ ⋅ 256² + b₂ ⋅ 256 + b₃

c₄ = N mod 85 + 33

c₃ = ⌊N ÷ 85⌋ mod 85 + 33

c₂ = ⌊N ÷ 85²⌋ mod 85 + 33

c₁ = ⌊N ÷ 85³⌋ mod 85 + 33

c₀ = ⌊N ÷ 85⁴⌋ + 33

Where b₀…b₃ are the input bytes (big-endian order), c₀…c₄ are the output ASCII code points, and 33 is the offset to shift into printable range (starting at !). If N = 0, the entire 5-character group is replaced with the single character z. For a trailing group of n bytes (1 - 3), pad with zero bytes to 4, encode normally, then output only the first n + 1 characters.

Reference Data

Property	Base64 (RFC 4648)	Ascii85 (btoa / Adobe)
Alphabet size	64 symbols	85 symbols
Character range	A - Z, a - z, 0 - 9, +, /	ASCII 33 (!) to 117 (u)
Padding character	= (up to 2)	None (length-implied)
Delimiters	None	<~ ... ~>
Input block size	3 bytes	4 bytes
Output block size	4 characters	5 characters
Expansion ratio	4÷3 ≈ 1.333	5÷4 = 1.25
Size overhead	≈ 33.3%	≈ 25%
Zero-block shortcut	No	z = 4 null bytes
Whitespace handling	Ignored by most decoders	Ignored between delimiters
Primary use case	Email (MIME), URLs, JSON, XML	PostScript, PDF streams
Defined in	RFC 4648 (2006)	btoa(1) Unix, Adobe spec (1992)
URL-safe variant	Yes (- and _ replace + and /)	No standard variant
Bits per character	6	6.41 (log₂85)
Max encodable value per block	2²⁴ − 1	2³² − 1
Binary safety	Yes	Yes

Frequently Asked Questions

Base64 uses a 64-symbol alphabet, encoding 6 bits per character. Ascii85 uses 85 symbols, encoding log₂(85) ≈ 6.41 bits per character. Over a 4-byte block, Base64 needs 8 characters (including padding) while Ascii85 needs only 5. The net overhead drops from 33.3% to 25%. For a 1 MB file, that saves roughly 85 KB.

This converter will attempt to process the raw data without delimiters, stripping whitespace and treating the content as a bare Ascii85 stream. However, this is technically non-conformant with the Adobe specification. If your data originates from a PDF or PostScript file, the delimiters should be present. Missing delimiters can indicate a truncated or corrupted stream.

When a full 4-byte input group consists entirely of zero bytes (0x00000000), the encoder replaces the 5-character output !!!!! with the single character z. This provides additional compression for null-heavy data. The shortcut is never applied to partial trailing groups. During decoding, each z expands to 4 null bytes.

Yes. Both Base64 and Ascii85 operate on raw byte arrays, not character strings. The converter decodes Base64 to bytes via a binary string intermediary, preserving all 256 possible byte values. No UTF-8 interpretation is applied to the intermediate binary. The output encoding then maps those bytes without loss. If you paste the final Ascii85 into a system that expects UTF-8 text, it remains valid because all Ascii85 characters fall within the ASCII printable range.

A single group encodes 4 bytes, representing values from 0 to 2³² − 1 = 4,294,967,295. The highest valid Ascii85 group is s8W-! which decodes to 0xFFFFFFFF. Any 5-character group that decodes to a value exceeding this limit is invalid and will produce a decoding error.

Yes. Trailing bytes are padded with 0x00 on the right to form a complete 4-byte block. After encoding, only the first n + 1 characters are emitted (where n is the number of real bytes: 1 - 3). During decoding, a short final group is padded with u (the highest Ascii85 character, value 84) on the right to 5 characters, decoded to 4 bytes, and then truncated to the correct count.