Base85 Encoder Decoder
Encode files or text to Base85/Ascii85 and decode it back.
Base85 Encoder Decoder
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The Base85 Encoder Decoder (also known as Ascii85) converts binary data into text using an 85-character alphabet, achieving noticeably better space efficiency than Base64: encoding 4 raw bytes into 5 ASCII characters is only a 25% size increase, compared to Base64's roughly 33% overhead for the same data. The tradeoff is a wider, less URL-friendly character set — Base85's 85 characters include punctuation marks that need escaping or special handling in URLs, email, and certain markup contexts where Base64 (deliberately restricted to alphanumerics plus two symbols) is safer to embed directly.
- Base85 has no single unifying IETF standard the way Base64 does — it's most closely associated with Adobe's Ascii85 scheme, documented in Adobe's own PostScript and PDF format specifications, where it's used to embed binary image and font data inside otherwise text-based document formats. Git uses a related but distinct Base85 variant for encoding binary content within text-based patch files, and ZeroMQ's Z85 is yet another distinct variant with its own alphabet ordering optimized for use in source code — all three solve the same 4-bytes-to-5-characters problem, but aren't necessarily interchangeable with each other without confirming which specific variant a given system expects.
How It Works
- Input data is processed in 4-byte groups, each treated as a single 32-bit number.
- That 32-bit number is converted to base 85, producing 5 characters from the Base85 alphabet — 85^5 is just over 2^32, enough to represent every possible 4-byte value.
- In the Adobe Ascii85 convention, the encoded output is conventionally wrapped in <~ and ~> delimiters, marking the start and end of an Ascii85-encoded block within a larger document.
- Decoding reverses this: delimiters are stripped, and each 5-character group is converted back to its original 4-byte value.
Usage
- Paste the text or data you want to encode, or the delimited Base85 string you want to decode.
- Click Encode or Decode as needed.
- Review the result.
- Copy the output for use in a document format or system that expects Base85/Ascii85 content.
Examples
- Encoding binary content for embedding within a PostScript or PDF document following the Ascii85 convention.
- Comparing Base85's output length against Base64's for the same input, to see the concrete space-efficiency difference in practice.
- Decoding an Ascii85-delimited block extracted from a document to inspect its underlying binary content.
- Deciding between Base85 and Base64 for a new binary-to-text encoding need based on whether the target context can tolerate Base85's wider, less URL-safe character set.
Real-World Use Cases
- Embedding binary data (such as image or font content) within a text-based document format that supports the Ascii85 convention, such as PostScript or PDF.
- Choosing a more space-efficient alternative to Base64 for a context that doesn't need Base64's stricter URL-safe character set.
- Understanding the Base85 family's tradeoffs (efficiency versus character-set breadth) before choosing it over Base64 for a specific binary-to-text transport need.
- Working with Git's binary patch format, which uses its own Base85 variant to represent binary file changes within an otherwise plain-text diff.
Best Practices
- Choose Base85 over Base64 specifically when space efficiency matters more than URL-safety or a narrow character set — its 25% overhead beats Base64's 33% for the same data.
- Confirm which Base85 variant (Adobe Ascii85, Git's variant, Z85, or another) a target system actually expects before assuming interoperability — the family shares a core idea but isn't universally interchangeable in exact alphabet or delimiter convention.
- Avoid Base85 for contexts requiring URL-safe or email-safe text, where its punctuation-heavy alphabet is more likely to need escaping than Base64's narrower character set.
- Use Base64 instead of Base85 when broad, unambiguous tooling support matters more than the modest space savings, since Base64 remains far more universally implemented and recognized.
Common Mistakes
- Assuming any Base85-labeled data is automatically compatible with any other Base85 implementation — the Adobe, Git, and Z85 variants differ in specifics and aren't guaranteed interchangeable without confirming the exact variant in use.
- Choosing Base85 for a URL or email context without checking whether its wider character set (including punctuation) will need additional escaping in that context, unlike Base64's deliberately narrower alphabet.
- Overestimating Base85's space savings — the actual improvement over Base64 is real but modest (25% versus 33% overhead), not a dramatic reduction.
- Assuming Base85 provides any confidentiality — like every encoding in this hub, it is fully reversible without any secret and provides no protection for sensitive data.
Limitations
- Base85 covers a family of related but distinct variants (Adobe Ascii85, Git's variant, Z85, and others); this tool's implementation reflects the general Ascii85 pattern conceptually and may not exactly match every specific variant's edge-case handling.
- Base85's wider character set makes it less suitable than Base64 for URL, email, or markup contexts without additional escaping.
- Base85 encoding is not encryption and provides no confidentiality.
Technical Reference Guide
- Ascii85, the specific Base85 variant most commonly referenced, is documented within Adobe's PostScript Language Reference Manual and the PDF specification, where it's used to embed binary data in otherwise text-based document content.
- Git uses a related but distinct Base85 encoding for representing binary file changes within text-based patch and diff output.
- Unlike Base16/32/64 (all defined together in RFC 4648), no single IETF RFC governs the Base85 family — each major variant (Adobe's, Git's, ZeroMQ's Z85) is documented independently by its respective originating project or specification.
FAQ
Is Base85 more efficient than Base64?
Yes — Base85 has about 25% size overhead versus Base64's roughly 33%, since it packs 4 bytes into 5 characters using an 85-character alphabet instead of Base64's 6-bits-per-character, 64-character scheme.
Why isn't Base85 more widely used if it's more efficient?
Its wider alphabet includes punctuation characters that aren't safe to use directly in URLs, email, or many markup contexts without escaping — Base64's narrower, more conservative character set makes it safer to embed directly in far more contexts, which outweighs the modest efficiency loss for most uses.
Are all Base85 variants the same?
No — Adobe's Ascii85, Git's binary patch variant, and ZeroMQ's Z85 are related but distinct schemes with different specific alphabets or conventions. Confirm which variant a target system expects before assuming compatibility.
What are the <~ and ~> markers in Ascii85 output?
They're Adobe's conventional delimiters marking the start and end of an Ascii85-encoded block within a larger document, distinguishing encoded binary content from the surrounding plain text.
Where is Base85 actually used in practice?
Adobe's PostScript and PDF formats for embedding binary image and font data, and Git's patch format for representing binary file changes within text-based diffs, are the two most common real-world applications.
Does Base85 provide any security or confidentiality?
No — like every encoding scheme in this hub, it's fully reversible without any secret and provides no confidentiality. It's purely a binary-to-text representation choice.
Part of this Developer Hub
This utility is part of our comprehensive Encoding & Conversion topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Encoding & Conversion Lab workshop for complementary engineering workflows.
View all Encoding & Conversion Lab tools