Ascii85 / Base85 encoder
“Hello, world!” becomes 87cURD_*#TDfTZ)+T in Adobe Ascii85, also called Base85, which packs every four bytes into five printable characters, denser than Base64, as PDF and PostScript tools expect. It decodes back, too. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- Hello, world!
- Result
- 87cURD_*#TDfTZ)+T
- Calculation mode
- Encode
- Variant
- ascii85
- Bytes
- 13
Ascii85, also called Base85, packs binary data into a denser printable alphabet than Base64 by mapping every four bytes to five characters drawn from the eighty-five symbols between exclamation mark and lowercase u, with a special z shorthand for runs of zero bytes. Encoding is deterministic UTF-8 then Adobe Ascii85 arithmetic; decoding accepts optional less-than-tilde and tilde-greater-than delimiters, strips whitespace, and rejects illegal symbols instead of inventing silent replacements.
Encode UTF-8 text to Adobe Ascii85 / Base85
The engine interprets the string as Unicode text, serializes it to UTF-8 bytes, then groups those bytes four at a time into a big-endian thirty-two-bit value and expands each group into five characters from the Adobe alphabet that runs from exclamation mark through lowercase u. When a full four-byte group is all zeros, a single z is emitted instead of five exclamation marks, which is the classic zero-run compression people expect from PDF and PostScript tooling.
A final partial group of one to three bytes is padded with zeros for arithmetic, then only n plus one characters are emitted for n remaining data bytes so the decode side can recover the exact length. Empty strings are valid and encode to an empty result with zero bytes. Multilingual text, emoji, and punctuation all round-trip because the path is full UTF-8, not a Latin-1 shortcut.
Identical inputs always produce identical outputs because the algorithm is pure arithmetic with no network, no random salt, and no wall clock. Use this path whenever you need a denser text-safe representation than Base64 for short configuration fragments, documentation samples, or Adobe-style binary-in-text channels.
Decode Base85 back to text and handle invalid characters
Set mode to decode and put an Ascii85 or Base85 string in text. Leading and trailing whitespace, including spaces, tabs, and newlines, is stripped so multi-line pastes still work. The alphabet is strict: only characters from exclamation mark through lowercase u, plus the standalone z for four zero bytes, are accepted.
Incomplete final groups shorter than two alphabet characters (when not z) are rejected; short final groups of two to four symbols are padded with u for arithmetic and yield one fewer byte than the symbol count, matching Adobe rules. Successful decode returns result as the recovered string, mode decode, variant ascii85, and bytes as the decoded UTF-8 length.
Prefer this capability when your search intent is literally Ascii85 encoder, Base85 decoder, or adobe ascii85 convert for human-readable content; binary image data URIs and standard Base64 remain separate tools with their own landings.
FAQ
How do I encode text to Ascii85 / Base85?
The response result field holds the Ascii85 string and bytes is the UTF-8 length.
How do I decode Base85 back to text?
Set mode to decode and put the Ascii85 string in text. Optional Adobe <~ ~> wrappers and whitespace are accepted. The result field is the recovered UTF-8 text.
What happens on an invalid Base85 character?
Characters outside the Adobe alphabet (! through u) and the special z for zero runs are rejected; validation failures are not charged.
Is the Ascii85 Base85 encoder free?
The browser tool runs free on your device.
How is this different from Base64?
Ascii85 uses an 85-symbol alphabet and packs four bytes into five characters (about 25% overhead versus ~33% for Base64). This tool implements Adobe Ascii85, not the RFC 4648 Base64 alphabet.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/base85 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Hello, world!"}'const res = await fetch("https://api.kit.forhosting.com/enc/base85", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "Hello, world!"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/base85",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "Hello, world!"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/base85", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"Hello, world!"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"Hello, world!"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/base85", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "Hello, world!"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.base85",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
People search for an Ascii85 encoder or Base85 decoder when they work with PDF streams, PostScript fragments, legacy Adobe-style payloads, or any pipeline that prefers a more compact text-safe form than classic Base64. This capability focuses on that everyday job: choose mode encode or decode, send a text field, and receive the transformed string plus byte length, or a clear invalid_input error when a decode payload contains a character outside the Base85 alphabet.
Encode UTF-8 text to Adobe Ascii85 / Base85
Send a JSON body with the required string field text set to the plain message you want to represent in Ascii85, and leave mode at its default encode or set mode to encode explicitly. Optional aliases input, value, and s are accepted for the same field when you generate clients from older form names. The response always includes result with the Ascii85 string, mode equal to encode, variant equal to ascii85, and bytes equal to the UTF-8 length before encoding so you can assert payload size in tests.
Decode Base85 back to text and handle invalid characters
Optional Adobe delimiters less-than-tilde at the start and tilde-greater-than at the end are removed when present; payloads without delimiters are equally valid. Any other character—including letters after u, URL-safe punctuation borrowed from other encodings, or binary noise—causes an immediate invalid_input failure with a message that names the invalid Base85 character condition, so clients can fix the paste instead of receiving corrupted Unicode. After alphabet validation, the recovered bytes are decoded as UTF-8 with a fatal decoder: if the payload is not valid Unicode text, you get invalid_input instead of replacement characters that would corrupt downstream displays. Validation failures are not charged on the prepaid API, so probing a suspicious token is cheap for operators and safe for end users.
API usage, pricing, workflows, and practical limits
Call the free in-browser Ascii85 Base85 encoder for classroom demos, support playbooks, PDF stream checks, and one-off conversions without installing OpenSSL wrappers or language-specific packages. A typical workflow encodes a short configuration value for storage in a text-only ticket, ships it through email or chat, then decodes it on the receiving service with mode decode and asserts that bytes match the original length. Authors shipping SDKs can map the result field straight into a copy button, while mode and variant labels make OpenAPI examples self-explanatory for readers who only know the Adobe alphabet and the z zero-run shorthand. Use the prepaid KIT API when a backend, serverless function, or SDK needs the same encode or decode step under balance at $0.002 per successful item; failed validation never consumes balance after the engine rejects the request. Pair this endpoint with a Base64 tool when a partner system only speaks Base64, but keep the steps on separate landings so each page matches a single search intent—Ascii85 density versus Base64 ubiquity.
Integration use cases
PDF and PostScript Ascii85 streams
Encode or decode Adobe-style Ascii85 payloads when inspecting PDF filters, PostScript fragments, or legacy binary-in-text channels that expect the classic alphabet and z zero runs.
Denser text-safe config tokens
Pack short UTF-8 configuration fragments more tightly than Base64 for tickets, chat, and JSON, then decode on the receiving service with the same mode field.
Docs and CI golden checks
Pin encode and decode fixtures so documentation samples and continuous-integration tests fail fast if the Ascii85 alphabet or incomplete-group rules ever drift.