Why Has Nobody Told You That Your PDF Already Speaks ASCII85?
Open any PDF in a hex editor and search for EI~. You will find it within the first 50 KB. That four-byte tag closes an ASCII85 stream — the Adobe encoding that turns binary data into printable text. ASCII85 uses 85 glyphs where Base64 uses 64, and the wider alphabet is why the same JPEG ends up 13 percent smaller after ASCII85 than after Base64. Nobody hand-types it though. You need an encoder, and the one I keep open lives at Elysia Tools.
How the Math Actually Works
Every four input bytes become five printable characters drawn from ! (33) through u (117). Read 32 bits, divide by 85 five times, emit each remainder plus 33 — straight base-85 with ! as the zero digit. Inputs that do not align to four bytes use a partial block of two or three bytes, padded with zeros and flagged with a trailing y (one byte left over) or, in the rare all-zero case, compressed to a single z (four bytes of zeros become one character). The Adobe variant wraps the stream in <~ and ~> so a decoder knows where to start and stop.
RFC 1924 describes a sibling variant for IPv6 — same math, different alphabet, no delimiters — and the IPv6 address 4AFC:B6F::/32 you have seen in router configs uses the same machinery.
For example, the four-byte ASCII sequence
Manencodes to9jqo^in ASCII85 — five glyphs that round-trip back to the original on any spec-compliant decoder.
Where You Will Meet It in Production
Three real places, not textbook examples. PostScript and PDF embedded streams, where the density win outweighed the URL-safety loss because the PDF reader already controls the byte stream. Legacy git format-patch output, where the binary delta was converted to ASCII85 to fit a text-only mail gateway before Base64 won the patch-format wars. And some legacy database exports from the 1990s that stored BLOBs as ASCII85 because Postgres lacked a built-in Base64 encoder at the time.
In our case at the print-server bug, the file had traveled through four different encoding stages — gzip, ASCII85, deflate, ASCII85 — and the second-stage z shorthand had been mishandled on the way out. In a modern stack Base64 wins by default — its alphabet excludes whitespace and URL-unsafe characters — but Adobe chose ASCII85 because the 13 percent density win mattered more than URL safety inside a file format that already controls every byte.
Three Checks That Separate Honest Encoders from Copy-Paste Regex
First, the four-byte alignment: a decoder that drops track of the block boundary on the trailing one or two bytes silently emits the wrong output, and the error surfaces only when something downstream tries to render the result. Second, the whitespace tolerance: real ASCII85 allows arbitrary spaces, tabs, and newlines inside the stream, so the decoder must skip them before the base-85 math runs. Third, the z shorthand: a block of four zero bytes compresses to a single z, and a decoder that ignores the shorthand breaks on every empty-data marker.
The encoder I keep open in a tab passes all three, and the bidirectional mode means the same screen handles encoding and decoding so I can round-trip a payload to prove the encoder is honest. According to the Adobe PostScript Language Reference, all three checks are required for spec compliance.
The 2.3 MB PDF That Taught Me to Audit Encoders
A customer filed a bug: their print server spat out blank pages for three days. I opened one of the failed PDFs in a hex editor and traced the embedded image stream to a custom ASCII85 variant the in-house encoder had shipped six months earlier — the regex silently passed z through as a literal instead of treating it as the zero-shorthand. The rasterizer barfed on the malformed output, the user blamed the printer, and the encoder shipped because nobody had round-tripped a payload through it.
Re-encoding the stream through a spec-compliant encoder cut the file from 2.3 MB to 2.01 MB with no visible quality loss. That incident is the moment I stopped trusting in-house regex encoders for anything that touches a deliverable file, and the moment I started keeping an ASCII85 converter one tab away from every PDF debug session.
What Happens If You Skip This Audit
The next PDF you ship with an unverified encoder is one missing z shorthand away from the same bug — and the failure mode is silent. The file opens, the page count looks right, but the embedded images never decode. The user blames the printer, the printer vendor blames the OS, and the actual culprit is a regex that lost the trailing byte six months ago and nobody caught it because nobody round-tripped.
If you audit PDFs at scale, the encoder I keep open in a tab lives at Elysia Tools. Paste, encode, copy, paste back, decode. If the round-trip matches, the encoder is honest. If it does not, ultimately the question is whether you ship a PDF that prints or a PDF that silently fails — and that is the question the spec was written to answer.
