# Base85 Encoder / Decoder

Canonical URL: https://offlineutils.com/base85
Category: Developer
Published: 2026-08-02
Publisher: offlineutils.com
Runs entirely in the browser; nothing entered into the tool is uploaded.

> A Base85 Encoder / Decoder converts binary data to and from an 85-character alphabet, packing four bytes into five characters for 25% overhead instead of Base64's 33%, supporting Adobe's Ascii85 as used in PDF and ZeroMQ's Z85.

Four bytes become one 32-bit integer written as five base-85 digits, which makes Base85 the densest of the common binary-to-text encodings — 25% overhead against Base64's 33%. Two flavours matter in practice. Ascii85 is Adobe's, embedded in PDF and PostScript streams, with a 'z' shorthand for four zero bytes and optional <~ ~> delimiters. Z85 is ZeroMQ's RFC 32, whose alphabet deliberately excludes quotes, backslashes and commas so the output can be pasted straight into source code, JSON or a shell command without escaping. Both are validated properly here, which is where most online encoders fall short: a five-character group can encode a value above 2^32-1 — 's8W-#' and anything above it — and that is malformed input which has to be rejected rather than silently wrapped. Z85 is also specified only for inputs that are a whole number of four-byte words, so this tool refuses a ragged input by default and, if you ask it to pad anyway, tells you the padding is not recoverable by a decoder.

## Features

- Ascii85 (Adobe) with the 'z' zero shorthand and optional <~ ~> delimiters
- Z85 (ZeroMQ RFC 32) with its source-code-safe alphabet
- Rejects groups that overflow 32 bits instead of wrapping silently
- Enforces Z85's four-byte word requirement, with opt-in padding that warns
- Decodes btoa's non-standard 'y' shorthand, and flags it as non-standard
- Input and output as text, hex bytes or Base64
- Shows the real size overhead so you can compare against Base64

## Use cases

- Reading an Ascii85 stream out of a PDF or PostScript file
- Embedding a binary key in source code or JSON without escaping problems
- Squeezing binary into a text field where Base64 would not fit
- Encoding a ZeroMQ CURVE key for a configuration file

## How to use it

1. **Choose the variant** — Ascii85 for PDF and PostScript data, Z85 for ZeroMQ and anything going into source code.
2. **Set how the input should be read** — Switch from text to hex when the input is raw binary such as a key — Z85 in particular is almost always applied to bytes, not prose.
3. **Set the options** — For Ascii85, optionally wrap the output in <~ ~> or collapse zero groups to 'z'. For Z85, decide whether a ragged input should be zero-padded.
4. **Copy or round-trip** — Copy the output, or send it back to the input to confirm it decodes to what you started with.

## When to use it, and when to use something else

- **vs Base64** — use Base85 Encoder / Decoder when you need the extra density — 25% overhead against 33% — or you are working with PDF or ZeroMQ data that is already Base85. Use Base64 when you need maximum compatibility; Base64 is understood everywhere and Base85 is not.
- **vs Other online Ascii85 tools** — use Base85 Encoder / Decoder when you want overflow groups rejected rather than wrapped, Z85's word requirement enforced, and hex input for real binary. Use Other online Ascii85 tools when you only need a quick one-off conversion of plain text.

## Frequently asked questions

### How much smaller is Base85 than Base64?

Base85 encodes four bytes as five characters, a 25% expansion, while Base64 encodes three bytes as four characters, a 33% expansion. So Base85 output is roughly 6% shorter than the same data in Base64. That is a real saving on large embedded blobs, and irrelevant on short values — the more common reason to use it is that your data already is Ascii85 or Z85.

### What is the difference between Ascii85 and Z85?

The alphabet, and the strictness. Ascii85 uses the 85 printable ASCII characters starting at '!', which includes quotes, backslashes and commas — fine inside a PDF stream, awkward inside a string literal. Z85 chose a different 85 characters specifically to avoid those, so Z85 output can be pasted into source code, JSON or a shell command unescaped. Z85 also requires the input to be a whole number of four-byte words, where Ascii85 handles any length.

### Why does my Z85 input get rejected?

Because Z85 is only defined for inputs that are a multiple of four bytes, and encoded strings that are a multiple of five characters. It carries no length field, so there is no way to signal that trailing bytes were padding. You can turn on zero-padding to encode a ragged input anyway, but the decoder will hand back the padding bytes as data — you have to strip them yourself, and this tool warns you rather than pretending otherwise.

### What does the 'z' in Ascii85 output mean?

It is a shorthand for a group of four zero bytes, which are common in binary data. Instead of '!!!!!' the encoder can emit a single 'z'. Some encoders also use 'y' for four spaces, but that is a btoa extension rather than part of Adobe's specification — this tool decodes it and flags it, and never produces it.

### Why would a valid-looking Base85 group be rejected?

Because five base-85 digits can express values up to 85^5, which is about 4.44 billion, while four bytes only hold up to 4,294,967,295. Groups above that maximum — 's8W-!' is the largest valid one — are malformed. Encoders that ignore this wrap the value around and produce four wrong bytes with no complaint, so rejecting it is the correct behaviour even though it looks stricter.

## Related tools

- https://offlineutils.com/base64
- https://offlineutils.com/base32
- https://offlineutils.com/base58