offlineutils
100% offline
Developer
Free · no signup
Updated

Base85 Encoder / Decoder

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.

Used inside PDF and PostScript streams. Supports the 'z' shorthand for four zero bytes and optional <~ ~> delimiters.

About Base85 Encoder / Decoder

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.

What Base85 Encoder / Decoder does

  • 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

When to reach for Base85 Encoder / Decoder

  • 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 Base85 Encoder / Decoder

  1. 01

    Choose the variant

    Ascii85 for PDF and PostScript data, Z85 for ZeroMQ and anything going into source code.

  2. 02

    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. 03

    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. 04

    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 Base85 Encoder / Decoder vs alternatives

AlternativeUse Base85 Encoder / Decoder when…Use the alternative when…
Base64you need the extra density — 25% overhead against 33% — or you are working with PDF or ZeroMQ data that is already Base85.you need maximum compatibility; Base64 is understood everywhere and Base85 is not.
Other online Ascii85 toolsyou want overflow groups rejected rather than wrapped, Z85's word requirement enforced, and hex input for real binary.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

Base64 Encoder / Decoder

Encode text to Base64 and decode it back, all offline.

Base32 Encoder / Decoder

Encode and decode Base32 — RFC 4648, extended hex, Crockford and z-base-32.

Base58 Encoder / Decoder

Encode, decode and checksum-verify Base58 and Base58Check.

Related concepts