z-base-32 encoder & decoder
“Hello” becomes jb1sa5dx in z-base-32, Zooko's human-oriented Base32 alphabet that leaves out 0, 2, l and v and adds no padding, so codes stay short and are easy to read aloud or copy by hand. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- Hello
- Calculation mode
- Encode
- Result
- jb1sa5dx
- Length
- 8
- Input bytes
- 5
- Alphabet
- z-base-32
z-base-32 is Zooko Wilcox-O'Hearn's human-oriented Base32 variant: a carefully permuted thirty-two-symbol alphabet that favors easy reading, writing, and spoken transcription while still packing five bits per character. Unlike RFC 4648 Base32, it drops confusing look-alikes, reorders symbols so common sounds appear more often, and omits equals-sign padding so tokens stay short. This capability turns UTF-8 text into lowercase z-base-32 or recovers the original text from a z-base-32 string.
How z-base-32 packs bits with Zooko's alphabet
z-base-32 starts from the same five-bits-per-character idea as classic Base32, but the symbol table is completely different. The thirty-two characters are y b n d r f g 8 e j k m c p q x o t 1 u w i s z a 3 4 5 h 7 6 9 in that order. Digits zero and two, the letter ell, and the letter vee are excluded because they are easy to confuse with other glyphs when someone reads a code aloud or copies it by hand.
The remaining symbols are ordered so that vowels and frequent consonants tend to appear earlier in the value space, which makes random strings slightly more pronounceable. Encoding treats your input as UTF-8 bytes, reads them as a continuous bit stream, and emits one alphabet character for every five bits. Any leftover bits at the end are zero-padded on the right to fill a final quintet; no equals signs are appended.
Decoding reverses the map: each symbol contributes five bits, full bytes are emitted as soon as eight bits accumulate, and any residual padding bits that do not form a complete byte are discarded. Whitespace is ignored so multi-line pastes still work, and uppercase letters are folded to lowercase before lookup.
Where z-base-32 shows up in real work
Human-facing identifiers that must be read over a phone, written on paper, or typed from a screenshot benefit from an alphabet that avoids ambiguous glyphs. z-base-32 was designed for exactly that: open-source systems such as Mnet and Tahoe-LAFS, and protocols such as ZRTP, adopted it so users could exchange compact codes without the zero-versus-O and one-versus-I traps of denser alphabets.
Product teams building offline recovery phrases, short air-gapped auth codes, or support desk one-time tokens often prefer Zooko's table when the string will be spoken or transcribed rather than only scanned by a machine. Engineering groups writing interoperability tests need a single ground truth for encode and decode that matches their own libraries and never silently substitutes illegal characters.
Curriculum authors teaching encoding schemes want a dedicated landing for z-base-32 instead of burying it under RFC 4648 Base32, because learners search for Zooko, human Base32, and padding-free tokens as separate intents. Support staff pasting multi-line codes from chat need whitespace tolerance without accepting garbage symbols that would produce a wrong key. If you need classic RFC 4648 Base32 with A-Z and two through seven, Base64, or Crockford Base32, treat those as separate landings rather than overloading this z-base-32 encoder page.
What you can do with it
Spoken and handwritten recovery codes
Encode short secrets as z-base-32 so users can read them aloud or write them down without confusing zero, ell, vee, or two with similar glyphs.
Human-friendly offline tokens
Produce compact, padding-free identifiers for air-gapped auth, support desk one-time codes, or product URLs that people type by hand.
FAQ
Which alphabet does z-base-32 use?
Zooko's permuted alphabet ybndrfg8ejkmcpqxot1uwisza345h769. It excludes 0, l, v, and 2, and does not use '=' padding.
How is this different from RFC 4648 Base32?
RFC 4648 uses A-Z and 2-7 with optional equals padding. z-base-32 uses a different symbol order, drops ambiguous characters, and omits padding. They are not interchangeable.
Can I both encode and decode?
Yes. Set mode to encode (default) to turn plain UTF-8 text into z-base-32, or mode to decode to recover text from a z-base-32 string.
What happens if the string has an invalid character?
Symbols outside the Zooko alphabet are never substituted. Nothing is charged for validation failures.
What does it cost?
The browser tool is free and runs locally.
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/base32-zbase \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Hello"}'const res = await fetch("https://api.kit.forhosting.com/enc/base32-zbase", {
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/base32-zbase",
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/base32-zbase", 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/base32-zbase", 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.base32_zbase",
"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
Encode mode packs your bytes into the alphabet ybndrfg8ejkmcpqxot1uwisza345h769; decode mode folds case, strips whitespace, and rejects any illegal symbol with a clear invalid_input error so a mistyped character never silently becomes the wrong payload.
How z-base-32 packs bits with Zooko's alphabet
A character outside the alphabet raises invalid_input with the position and the offending symbol, which is the correct failure mode for tokens that people type under stress. The path is pure integer bit packing with no network calls, no random seeds, and no wall-clock timestamps, so identical inputs always produce identical JSON. This page is deliberately not RFC 4648 Base32 and not Crockford Base32; those alphabets and padding rules are different search intents with different interop targets.
What you send and what you get back
Send a required string field named text and an optional mode field set to encode or decode. Encode mode treats text as plain UTF-8 content and returns a lowercase result string in the Zooko alphabet with no padding. Decode mode treats text as z-base-32, normalizes case and whitespace, validates every symbol, and returns the recovered UTF-8 string in result. Both directions echo mode, the original text, result, a length field for the primary output string, alphabet and charset labels, a padding flag set to false, and a short standard reference so clients can assert which profile they hit. Typical checks include encoding a short word such as Hello, decoding the round-trip string back to the same text, and forcing an error by pasting a symbol that z-base-32 deliberately excludes, such as zero or the letter ell. When mode is omitted, encode is the default so a minimal payload still does useful work. Encode also reports input_bytes; decode reports output_bytes. Missing text, non-string objects, unsupported mode values, strings longer than the documented maximum, illegal alphabet characters, or decoded bytes that are not valid UTF-8 all fail with invalid_input and a clear English message. Validation failures do not consume prepaid balance. Pricing for successful API calls is the published base of $0.002 per item.
Where z-base-32 shows up in real work
Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance.
Integration use cases
Interop fixtures for Zooko libraries
Generate encode and decode golden vectors that match z-base-32 libraries used in ZRTP, Tahoe-style systems, and related open-source tools.