What Is ASCII85 and When Would You Actually Use It?
ASCII85 encoding is a way to turn binary data into printable text with less overhead than Base64. It shows up when a file or protocol needs bytes to travel through a text-only channel, and you want the payload to stay relatively compact. If you want to poke at it directly, give the ASCII85 encoder a spin.
What ASCII85 Actually Is
ASCII85, sometimes called Base85, is an encoding scheme, not compression. It takes raw bytes and maps them to a smaller set of printable characters so the data can survive systems that only handle text cleanly.
The usual trick is simple: take 4 bytes of input, treat them as a 32-bit integer, then express that number using 5 printable ASCII characters. Since 5 characters can represent a large range of values, the output is denser than Base64. That density is the whole point.
It does not make data smarter. It does not reduce entropy. It just changes the wrapper.
Why Use It Instead of Base64
Base64 is everywhere because it is easy, safe, and supported almost everywhere. ASCII85 is less common, but it has one major advantage: it is more compact. Base64 expands data by about 33 percent; ASCII85 expands it by about 25 percent.
That difference matters when the encoded text is large or when the format was designed around printable tokens. If you are embedding binary inside a PostScript file, a PDF stream, or another text-oriented format, shaving off some size can be useful.
There is a tradeoff, of course. ASCII85 is less ubiquitous than Base64, so interoperability can be weaker. If you need maximum compatibility across browsers, APIs, or old tools, Base64 still wins by brute force.
For a broader refresher on the older sibling, see why Base64 shows up everywhere.
Where Developers Actually Run Into It
The most common place ASCII85 appears is in PostScript and PDF workflows. PDF supports ASCII85 as a filter for compressing or packaging streams, especially in older or low-level document pipelines. You might also see it in tools that emit printer-ready output or in archival formats that were designed before today’s blob-and-JSON world.
It can show up in email, documentation, or old software that wants binary-safe text without the padding noise of Base64. That said, in modern web apps it is more of a niche tool than a daily driver. Most teams reach for Base64, percent encoding, or plain binary transfer over HTTP instead.
So the practical rule is boring but accurate: use ASCII85 when the format asks for it, or when a denser text encoding gives you a small but meaningful win. Do not choose it just because it sounds lower-level.
How the Encoding Works Under the Hood
ASCII85 works on fixed-size chunks. Every 4 bytes become 5 characters, because 4 bytes give you 32 bits of input, and 5 base-85 digits can represent that full range. When the input length is not a clean multiple of 4, the encoder pads the final block and then trims the extra output accordingly.
That block-based design is why it is efficient, but it is also why you need a decoder that understands the rules. Some implementations add shortcuts, like the special character z in Adobe-style ASCII85 to represent four zero bytes. That saves space, but it is a format detail, not a universal law.
A tiny conceptual version looks like this:
raw bytes: 4 bytes at a time
number: 32-bit integer
encode: convert to 5 printable base-85 digits
output: ASCII textWhat matters is the reversible mapping. If the encoder and decoder agree on the alphabet, padding, and any special shortcuts, the original bytes come back exactly.
When ASCII85 Is a Bad Choice
ASCII85 is not the right answer when compatibility matters more than compactness. Many systems and libraries do not support it by default, while Base64 support is nearly universal. If you are sending data through JSON, form fields, APIs, or browser code, Base64 is usually the safer bet.
It is also a poor choice when you do not control both ends of the pipeline. If you are not sure the receiving system knows how to decode ASCII85, you are just creating a future decoding ticket. Hidden complexity is still complexity.
And if you are trying to reduce size for storage or bandwidth, remember that encoding is not compression. If you need real reduction, you want gzip, Brotli, zstd, or a similar compressor before encoding the result for transport.
Binary to Text Is a Transport Problem, Not a Magic Trick
Encoding schemes like ASCII85 exist because some channels are hostile to raw bytes. Old mail systems, text-only editors, line-based file formats, and printer descriptions all prefer printable characters over arbitrary binary. ASCII85 is one way to smuggle bytes through those systems without corruption.
That makes it useful in a very specific band of problems:
- embedding binary assets inside text documents
- moving data through line-oriented pipelines
- storing binary blobs in formats that only allow printable text
- interfacing with legacy document or print tooling
If your problem is just “I need bytes in a web app,” you probably want something else. But if your problem is “this format expects text and the payload is binary,” ASCII85 is a reasonable tool to know.
See It in Action
Here is a simple example of the kind of transformation ASCII85 performs. The exact output can vary depending on the implementation and alphabet, but the shape of the conversion is the same: a short binary value becomes a compact printable string.
Input bytes (hex):
00 00 00 00
ASCII85 output:
z
Input bytes (hex):
48 65 6c 6c 6f
ASCII85 output:
87cURD]i,"That first example uses the common shorthand for four zero bytes. The second shows ordinary encoded text for the word Hello. If you decode that output with a compatible ASCII85 decoder, you get the original bytes back.
Here is a more practical workflow for a developer:
- Take a binary payload, such as an image fragment or document stream.
- Encode it with ASCII85 if the target format requires printable text.
- Paste or transmit the encoded text through the text-only system.
- Decode on the other side and verify the bytes match.
If you ever need to compare the byte-level result after decoding, our guide on how computers move between text and binary is a useful companion read.
Frequently Asked Questions
Is ASCII85 the same as Base85?
Pretty much, but not always exactly. ASCII85 is the Adobe/PostScript-flavoured variant most people mean when they say Base85, but there are other Base85 alphabets and formats in the wild. The encoding rules, shortcuts, and allowed characters can differ between implementations.
Is ASCII85 compression?
No. It is an encoding, which means it translates bytes into text without trying to remove redundancy. The output is usually smaller than Base64, but the original data is still fully there. If you want actual compression, use a compressor first.
Where is ASCII85 used in practice?
You will mostly see it in PostScript, PDFs, and some legacy document or print pipelines. It can also appear in older tools and niche data transfer workflows where printable text is required. In modern web development, Base64 is far more common.
Should I use ASCII85 or Base64?
Use Base64 if you want broad compatibility and simple support across languages and platforms. Use ASCII85 if the format already expects it, or if you specifically need a denser printable representation and control both encoder and decoder. Compatibility usually matters more than the few extra saved characters.
The Bottom Line
ASCII85 encoding is a compact way to wrap binary data in printable text. It is handy in the right kind of legacy or document-heavy workflow, but it is not a general-purpose replacement for Base64. The main decision is usually not “which is more elegant,” but “which one will the next tool in the chain actually understand.”
If you are working with a PDF stream, a PostScript file, or some other text-only pipe, test the round trip before you commit to it. And if you want a quick way to see what ASCII85 does to real input, use this ASCII85 encoder tool and check the output against your decoder.
Once you have the shape of it in your head, the format stops looking mysterious. It is just bytes wearing a text costume.