Git Base85 encoder
“hello” becomes the Git Base85 line EXk~0{ZvX%Q, where the leading E says the line holds five bytes: the dialect Git uses for binary patches, distinct from Adobe Ascii85. Encode text or raw bytes and decode lines back. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- hello
- Result
- EXk~0{ZvX%Q
- Calculation mode
- Encode
- Output format
- Text
- Variant
- git_base85
Git stores binary file changes inside unified diffs using a custom Base85 dialect, not Adobe Ascii85 and not plain Base64.
Encode text or hex into Git Base85 lines
For every chunk it writes a length prefix (A means one byte, B means two, up through Z for twenty-six, then a for twenty-seven through z for fifty-two) and expands each group of four bytes into five characters from Git’s eighty-five-symbol alphabet: digits, upper and lower letters, and the punctuation set that omits quotes, commas, periods, slashes, and backslashes so patches remain mail- and shell-friendly.
A final short group is zero-padded for arithmetic, then truncated to the correct number of five-character blocks so the decoder recovers the exact byte count from the prefix alone. Empty input is valid and yields an empty result with zero bytes and zero lines. The path is pure arithmetic—no network, no random salt, no clock—so identical inputs always produce identical Base85 bodies for continuous-integration goldens.
Decode length-prefixed lines and reject invalid input
Set mode to decode and put one or more Git Base85 lines in text. Blank lines are ignored so you can paste a fragment copied from a larger patch. After the prefix, the remainder must be exactly five times the number of four-byte groups needed for the declared byte count—too few or too many symbols is an error, not a silent truncate.
Every encoded character must sit in Git’s alphabet; a symbol borrowed from Adobe Ascii85 (for example a bare less-than or a z zero-run that Git does not use) fails immediately so you never mis-apply a foreign dialect as a binary patch body. Successful decode concatenates all lines in order into a single byte buffer.
How Git Base85 differs from Ascii85
People often search for a Base85 encoder after seeing binary data in a git diff, then land on Adobe Ascii85 tools that use a different alphabet, optional less-than-tilde wrappers, and a z shorthand for zero runs. Git’s dialect is intentionally distinct: fixed eighty-five symbols starting at digit zero, mandatory per-line length prefixes, no Adobe delimiters, and no z compression token. This landing is dedicated to that Git-specific search intent—git base85 encoder, git binary patch base85, decode git base85—so it does not compete with a general Ascii85 page.
Another workflow pastes only the data lines from a GIT binary patch (skipping the literal N header if you already know the size) and recovers bytes for inspection.
FAQ
How do I encode text to Git Base85?
The result field holds newline-joined lines, each starting with a length letter A–z, and bytes is the UTF-8 length.
How do I decode Git binary patch Base85 lines?
Set mode to decode and put the length-prefixed lines in text.
What makes Git Base85 different from Adobe Ascii85?
Git uses a different 85-character alphabet, requires a per-line length prefix (A–Z, a–z), does not use <~ ~> delimiters, and does not implement Adobe’s z zero-run shorthand.
Is the Git Base85 encoder free?
The browser tool runs free on your device.
What does the first letter of each Git Base85 line mean?
It is the length of that line in bytes: A means one, B two, up to Z for 26, then a for 27 through z for 52. A line never holds more than 52 bytes, and the decoder uses that letter to recover the exact byte count.
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-git \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"hello"}'const res = await fetch("https://api.kit.forhosting.com/enc/base85-git", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "hello"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/base85-git",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "hello"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/base85-git", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"hello"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"hello"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/base85-git", 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"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.base85_git",
"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
Each data line begins with a single length prefix letter—A through Z for one to twenty-six decoded bytes, a through z for twenty-seven to fifty-two—followed by five alphabet characters for every four payload bytes. Developers who inspect GIT binary patch sections, debug apply failures, or build tools that emit compatible payloads need a converter that speaks exactly that alphabet and line shape. This capability encodes UTF-8 text or hexadecimal bytes into Git Base85 lines, and decodes those lines back while rejecting illegal symbols, bad length prefixes, and mismatched group sizes with invalid_input. Successful API calls cost $0.002 per item; validation failures are not charged.
Encode text or hex into Git Base85 lines
Send a JSON body with the required string field text and leave mode at encode, or set mode to encode explicitly. By default format is text: the engine UTF-8 encodes your string, then walks the bytes in chunks of at most fifty-two octets—the same maximum Git uses on each binary-patch line. Set format to hex when your payload is raw binary: text must be an even-length hexadecimal string (spaces and underscores allowed), and those bytes are encoded without a UTF-8 layer. The response includes result (newline-joined lines), mode encode, format, variant git_base85, bytes (payload length before encoding), and lines (non-empty output lines).
Decode length-prefixed lines and reject invalid input
Each non-empty line must start with a valid length letter; any other first character fails with invalid_input naming the length-prefix rule. With format text (default) those bytes are interpreted as UTF-8 with a fatal decoder: invalid sequences raise invalid_input instead of emitting replacement characters that would corrupt downstream diffs. With format hex the result is a lowercase hex string of the recovered bytes, which is the practical choice when the payload is zlib-compressed literal data from a real GIT binary patch rather than human-readable text. The response echoes mode decode, format, variant git_base85, bytes as the decoded length, and lines as the count of non-empty input lines. Validation failures are not billed on the prepaid API, so probing a suspicious paste is safe for operators and cheap for scripts that gate merges on parse success.
How this differs from Ascii85, and how to use the API
Use the prepaid KIT API at $0.002 per successful item when a backend, bot, or continuous-integration job must emit or verify Git Base85 bodies under balance; failed validation never consumes that balance.
Integration use cases
Inspect GIT binary patch bodies
Decode length-prefixed Base85 lines copied from a git diff --binary so you can hex-dump the compressed literal payload without applying the whole patch.
Author compatible test fixtures
Encode known byte sequences into Git Base85 lines for unit tests of apply tools, merge bots, and documentation that must match git’s alphabet and length prefixes.
Catch dialect mix-ups in CI
Reject Adobe Ascii85 or corrupted paste as invalid_input before a pipeline treats foreign Base85 as a valid binary patch body.
Technical questions
What happens on invalid Base85 input?
Decode fails with invalid_input for bad length prefixes, characters outside the Git alphabet, wrong group sizes, or invalid UTF-8 when format is text. Validation failures are not charged.