Introduction
Base32768 splits the difference between density and portability. It packs 15 bits into each Unicode character drawn from a 32,768-code-point repertoire that stays within the Basic Multilingual Plane, so every output character fits in one UTF-16 code unit and survives most BMP-safe transports. That makes it a strong default for JavaScript, Java, and Windows applications that want more density than Base64 without the supplementary-plane risk of Base65536. This tool encodes and decodes Base32768 in your browser. Paste your text, choose the mode, and copy the result.
What this tool does
- Encodes UTF-8 text into Base32768 using a 32,768-code-point BMP repertoire, emitting 15 bits per primary character.
- Decodes Base32768 back to the original UTF-8 text, verifying padding bits and rejecting unknown characters.
- Handles trailing bits with a secondary 7-bit repertoire so any byte length round-trips losslessly.
- Ignores whitespace on decode, so wrapped output still parses.
- Runs entirely client-side with no server calls.
How this tool works
The encoder converts your input to UTF-8 bytes and walks the bit stream most-significant-bit first. Each time 15 bits accumulate, it looks up the matching character in the primary repertoire and appends it. When the input length is not a multiple of 15 bits, the final partial group is padded with 1s and emitted from a smaller 128-character secondary repertoire, making the encoding self-delimiting and lossless for any byte count.
Decoding reverses the process. Each character maps to a number of bits (15 for primary, 7 for the trailing secondary character) and a value. The tool reassembles the byte stream, checks that the padding bits are all 1s, and reports any character outside the repertoire or any secondary character appearing before the end. Whitespace in pasted input is ignored.
How Base32768 works
Base32768 was created by qntm as a BMP-only alternative to Base65536. The design target is UTF-16 storage, where each BMP code point occupies one 16-bit code unit. By encoding 15 bits per character and staying within the BMP, Base32768 achieves 1.875 bytes per UTF-16 code unit, compared with Base65536's 2 bytes per code unit, while avoiding supplementary-plane code points that some systems cannot represent.
The repertoire is drawn mostly from CJK ideograph and other BMP ranges chosen for platform safety. The selection avoids surrogates, control characters, combining marks, and code points that common systems normalize or strip. Because the output is BMP-only, it survives transports that handle the Basic Multilingual Plane but drop or replace supplementary-plane characters, which is a common failure mode for Base65536.
The 15-bit alignment means there is usually a small padding cost at the end of a payload, handled by the secondary repertoire. For most payloads the density is close to the theoretical maximum for BMP-only output. When the transport can handle the full code space, Base65536 is denser; when it counts characters and may mangle even some BMP blocks, Base2048 is safer.
How to use this tool
- Type or paste your text into the input field.
- Keep the mode on Encode to produce Base32768, or switch to Decode to recover the original text.
- The output updates instantly. Copy it with the copy button.
- On decode, paste Base32768 text. Whitespace is ignored; unknown characters raise an error.
- Use Swap to move the output into the input and flip the mode in one click.
Real-world examples
Embedding a binary token in a BMP-safe JSON field
A service stores session tokens in a UTF-16 database column that supports the BMP but not supplementary-plane characters. Base65536 output would be corrupted on write. Base32768 stays within the BMP, so the token survives intact. A 45-byte token encodes to 24 characters, versus 60 for Base64.
Compacting a payload for a chat bot that strips emoji
A chat platform strips supplementary-plane code points (where most emoji live) but preserves CJK and other BMP text. Base65536 output contains supplementary-plane characters and gets mangled. Base32768 uses BMP ranges including CJK ideographs, so it passes through cleanly. The recipient decodes it back to the original bytes.
Round-tripping a short binary identifier
Input `token-v2-9f3a` encodes to a handful of CJK characters. Decoding yields the exact original string. The tool handles the trailing bits via the secondary repertoire, so even short inputs with no special alignment round-trip without padding artifacts.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Base64 | 6 bits/char, ASCII | Email, JWTs, data URIs (RFC 4648) |
| Base2048 | 11 bits/char, Unicode BMP | Character-counted channels |
| Base32768 | 15 bits/char, Unicode BMP | UTF-16 storage, BMP-only |
| Base65536 | 16 bits/char, Unicode (non-BMP) | Maximum density, full code space |
Limitations or considerations
Base32768 is an encoding, not encryption, and offers no confidentiality. Its density advantage holds on UTF-16 or character-counted transports that preserve BMP code points. On a UTF-8 transport, each BMP character can take up to 3 bytes, so the byte footprint may exceed Base64. Some platforms normalize or strip even BMP characters from the CJK ranges the repertoire uses. Test the round-trip on your target transport before relying on it for production data.
Frequently asked questions
Why 15 bits instead of 16 like Base65536?
There are only 32,768 safe BMP code points available after excluding surrogates, control characters, and normalization-sensitive ranges. That fits 15 bits. Going to 16 bits would require supplementary-plane code points, which is exactly what Base65536 does at the cost of BMP portability.
Is Base32768 output valid CJK text?
The repertoire draws from CJK ideograph ranges, so the output looks like CJK characters, but it is not meaningful text. The code points are chosen for safety, not linguistic content. Do not expect the output to be readable Chinese, Japanese, or Korean.
When should I pick Base32768 over Base2048?
Pick Base32768 for maximum density on a UTF-16 transport that handles the full BMP. Pick Base2048 when the transport counts characters and may mangle some BMP blocks, since Base2048 uses a smaller, more conservatively chosen repertoire that survives harsher platforms.
Does Base32768 have an RFC?
No. Like the other Unicode base encodings from qntm, it is a community specification with a reference implementation, not an IETF standard. Interoperability requires both sides to use the same repertoire and bit ordering.
Conclusion
Base32768 is the pragmatic middle ground for Unicode binary encoding: 15 bits per BMP character, dense enough to beat Base64 on UTF-16 systems, and portable enough to survive BMP-only transports. Encode a payload above and compare it with Base64. If your transport handles the full code space, Base65536 is denser; if it is harsh on BMP blocks, Base2048 is safer.