Base32768 encoder & decoder
Pack text into Base32768, where each Unicode character carries fifteen bits for UTF-16 channels: Hello becomes just three characters, 䩲腻㐿. Decoding checks every symbol and the padding, so corrupted pastes fail. 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
- 䩲腻㐿
- Length
- 3
- Input bytes
- 5
- Bits per char
- 15
Base32768 is a binary-to-text encoding designed for channels that already speak UTF-16: JavaScript strings, Java String, Windows wide APIs, and many databases that store NVARCHAR.
How Base32768 packs fifteen bits into safe BMP characters
Base32768 treats the input as a continuous bit stream of raw bytes. For text, this capability first converts your string with UTF-8 so multi-byte characters stay portable across languages and platforms. Bits are then taken most-significant-first.
Every fifteen accumulated bits select one index in a 32768-entry primary repertoire built from closed ranges of assigned, non-control, non-whitespace Unicode code points in the Basic Multilingual Plane. Those ranges deliberately avoid characters that break under Unicode normalization, confuse text direction, or look like formatting, so the encoded string is safe to paste through most Unicode-clean APIs.
When the final remainder is not a full fifteen-bit block, the encoder pads with ones and either finishes with a primary symbol or with a dedicated seven-bit secondary padding symbol drawn from a separate 128-entry alphabet. Decoding reverses the map: each character contributes either fifteen or seven bits, full bytes are emitted as soon as eight bits accumulate, and the residual padding bits must still be all ones. A secondary padding character before the final position is also rejected, because that pattern can never appear in a legal encoding.
Compared with Base64, you trade an ASCII-only alphabet for far better density under UTF-16; compared with Base65536, you stay inside the BMP so every character is a single UTF-16 code unit.
Where Base32768 encoding shows up in real work
Systems that store binary blobs inside UTF-16 text columns often need denser packing than Base64 can offer without leaving the BMP. Teams that already standardized on the qntm suite of density encodings use Base32768 when the channel is UTF-16-native and Base2048 or Base65536 when different constraints apply. Curriculum authors teaching encoding density under different Unicode forms want one page dedicated to Base32768 rather than burying it under a generic Base64 landing, because search intent, alphabet rules, and efficiency numbers differ.
If you need RFC 4648 Base32 for TOTP secrets, URL-safe Base64, or basE91 density under UTF-8, treat those as separate search intents and landings rather than overloading this Base32768 encoder page.
FAQ
Which Base32768 profile does this use?
The qntm Base32768 profile: 32768 primary BMP code points carrying fifteen bits each, plus a 128-entry secondary alphabet for the final seven-bit padding symbol when needed.
Can I both encode and decode?
Yes. Set mode to encode (default) to turn plain UTF-8 text into Base32768, or mode to decode to recover text from a Base32768 string.
What does it cost?
The browser tool is free and runs locally.
Why does Hello become only three characters?
Each Base32768 character carries fifteen bits. Hello is five bytes, or forty bits, so three characters are enough, with the unused part of the last one filled with one bits.
Why is Base32768 denser than Base64 for UTF-16 text?
Base64 packs six bits into each ASCII symbol, while Base32768 packs fifteen bits into each character, and every character is a single UTF-16 code unit. Stored or sent as UTF-16, that gives roughly 93.75 percent efficiency.
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/base32768 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Hello"}'const res = await fetch("https://api.kit.forhosting.com/enc/base32768", {
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/base32768",
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/base32768", 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/base32768", 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.base32768",
"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
Instead of packing five or six bits into an ASCII symbol the way Base32 and Base64 do, Base32768 selects each character from a carefully chosen repertoire of 32768 safe Basic Multilingual Plane code points and carries fifteen bits of payload per character. That yields roughly 93.75 percent efficiency when the result is stored or transmitted as UTF-16, far denser than Base64 on the same wire. This capability implements the qntm Base32768 profile end to end: encode mode reads your plain string as UTF-8 bytes and emits a Base32768 result; decode mode validates every symbol against the primary fifteen-bit alphabet and the secondary seven-bit padding alphabet, then recovers the original UTF-8 text. Illegal symbols, padding characters in the wrong place, and padding bit mismatches fail immediately with invalid_input so corrupted pastes never look successful.
How Base32768 packs fifteen bits into safe BMP characters
Any character outside both repertoires raises invalid_input. The entire path is deterministic integer work with no network, no random seeds, and no wall-clock timestamps, so identical inputs always produce identical JSON.
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 result string in the Base32768 alphabets. Decode mode treats text as Base32768, validates every symbol, and returns the recovered UTF-8 string in result. When mode is omitted, encode is the default so a single payload still does useful work. Both directions echo mode, the original text, result, a length field for the primary output string, bits_per_char set to fifteen, alphabet and plane labels, and a short standard reference so clients can assert which profile they hit. Encode also reports input_bytes; decode reports output_bytes. Missing text, non-string objects, unsupported mode values, strings longer than the documented maximum, unrecognised Base32768 characters, a secondary padding character before the end, padding bit mismatches, 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. Classic checks include encoding Hello to a short three-character Base32768 block, encoding the phrase hello world to the well-known reference string published with the format, and decoding that string back to the original eleven-byte payload. Pricing for successful API calls is the published base of $0.002 per item.
Where Base32768 encoding shows up in real work
Game save blobs embedded in JSON, compact configuration fingerprints moved through clipboard APIs, and short offline tokens that must survive JavaScript string round-trips all benefit from fifteen bits per character. Support desks paste opaque strings from tickets and need strict alphabet validation without accepting garbage symbols that would produce a wrong payload. 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
UTF-16-dense opaque tokens
Encode short binary-safe payloads into Base32768 for storage in NVARCHAR columns, JavaScript strings, or clipboard transfer where UTF-16 density matters more than ASCII safety.
Cross-runtime golden fixtures
Generate encode and decode vectors that match the qntm Base32768 reference so multi-language CI shares one ground truth for fifteen-bit packing.
Strict paste validation
Decode user-pasted Base32768 strings with clear invalid_input errors when a symbol falls outside the primary or secondary alphabet.
Technical questions
What happens if the Base32768 string has an invalid character?
Decode fails with invalid_input describing the unrecognised symbol or padding problem. Nothing is charged for validation failures.
Why is Base32768 denser than Base64 under UTF-16?
Each Base32768 character is a single BMP code unit (16 bits of UTF-16) carrying fifteen payload bits, about 93.75 percent efficiency. Base64 needs two UTF-16 units for twelve payload bits of ASCII output, so density on UTF-16 wires is much lower.