ASCII85 Encoder API

About the ASCII85 Encoder API

An ASCII85 encoder and decoder for turning text into compact base-85 encoding and back. Send a string with action set to encode and you get the Base85 output with the original and encoded lengths; send an encoded string with action set to decode and you get the plain text back. Because every 4 bytes become 5 ASCII characters, the output is about a quarter larger than the input, compared with a third for Base64.

Developers use it when working with PostScript and PDF streams, when checking what a btoa-style encoder produced, or when they need printable text that survives copy and paste between systems.

The Free plan encodes and decodes in the standard format, without delimiters. Paid plans add the format option, which wraps output in the Adobe <~ and ~> markers or strips and checks them on decode, and they return the compression_ratio field so you can see the size overhead on each request.

How it works

Encoding reads the text as UTF-8 bytes and processes them in groups of four. Each group is treated as an unsigned 32-bit number and written as five base-85 digits, using the characters ! (33) to u (117). A full group of four zero bytes is shortened to the single character z. A final group with fewer than four bytes is padded with zeros, and only n+1 characters are kept for n input bytes, so no padding appears in the output.

format controls the delimiters. standard returns the bare digits; btoa wraps them in <~ and ~>. On decode with format=btoa, input that does not start with <~ and end with ~> is rejected with a 400. Whitespace inside an encoded string is ignored, characters outside the ! to u range return an error naming the position, and a final group of a single character is rejected because it cannot hold a byte. The decoded bytes are read back as UTF-8.

original_length and encoded_length are character counts of the input and output strings. compression_ratio is the encoded length divided by the original length, as a percentage with two decimals; for ASCII input it sits near 125%, plus 4 characters when btoa delimiters are added. Because it counts characters rather than bytes, non-ASCII input shows a higher ratio. On the Free plan the format parameter is ignored, so output is always standard, and format and compression_ratio are returned as null on encode.

What people use it for

Data Encoding

Encode binary data for text-based transmission with better compression than Base64

PDF Processing

Handle ASCII85-encoded data in PDF files and PostScript documents

Data Serialization

Serialize binary data for storage in text-based formats like JSON or XML

Compression

Achieve better compression ratios for binary data in text-only protocols

Ways to call it

One endpoint, many ways in — REST with JSON, XML, YAML and CSV, plus GraphQL and an MCP interface for AI agents.

JSON

Default REST response

XML

Markup format

YAML

Human-readable

CSV

Tabular export

Beta

GraphQL

Query language

New

MCP

For AI agents

Request parameters — GET /v1/ascii85encoder

Sent in the query string. Premium parameters are accepted on every plan but only take effect on plans that include them. Anything not listed here is dropped rather than passed through.

Required

Optional

1
2

curl "https://api.apiverve.com/v1/ascii85encoder?text=Hello%20World&action=encode&format=standard" \
  -H "x-api-key: YOUR_API_KEY"

Authentication

Send your key in the x-api-key header. That is the only auth step — no token exchange, and no per-endpoint scope to configure.

Response — GET /v1/ascii85encoder

Every APIVerve endpoint returns the same three top-level keys, so one response handler covers your whole integration: status, error and data. Only data changes shape.

1
2
3
4
5
6
7
8
9
10
11
12

{
  "status": "ok",
  "error": null,
  "data": {
    "original_text": "Hello World",
    "encoded": "87cURD]i,\"Ebo7",
    "format": "standard",
    "original_length": 11,
    "encoded_length": 14,
    "compression_ratio": "127.27%"
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

Response headers

Every response carries your balance, so your own code always knows where it stands without polling anything. All four are exposed to browsers through CORS.

Errors

Read the HTTP status first, then error for the specific reason. The body names the parameter that has to change.

What a call costs — 1 credits per call

Credits are shared across every APIVerve API — one balance, one key, one bill. Failed requests never count against it, so a rejected input costs nothing.

Calls are what the credits buy at this API's rate — spend them here, on any of the other APIs, or across both. Nothing is reserved per endpoint.

Zero-code embed — one snippet, no backend

Drop an interactive ASCII85 Encoder form onto any page. The widget calls the API for you, so no key ever appears in your markup and there is nothing to deploy.

Changelog — ASCII85 Encoder API

Every change to this endpoint, newest first. Breaking changes ship as a new version and the previous one keeps serving — response fields are added, never removed or retyped in place, so an integration written against v1 keeps working.

Currently v1