Introduction
Base65536 is the densest binary-to-text encoding that stays Unicode-clean. It maps two full bytes (16 bits) to a single Unicode character, so a 256-byte payload becomes 128 characters with no padding. For JavaScript, Java, and Windows applications that store strings as UTF-16, that is the theoretical maximum density. This tool encodes text to Base65536 and decodes it back in your browser. Paste your input, pick the mode, and copy the result. Nothing is sent to a server.
What this tool does
- Encodes UTF-8 text into Base65536, emitting exactly 16 bits (two bytes) per primary character.
- Decodes Base65536 back to the original UTF-8 text, rejecting unrecognised characters and trailing junk.
- Handles an odd byte count with a secondary 8-bit repertoire so any input length round-trips losslessly.
- Ignores whitespace on decode, so line-wrapped output still parses.
- Processes everything client-side; no payload ever leaves the browser.
How this tool works
The encoder converts your input to UTF-8 bytes and walks the bit stream most-significant-bit first. Each time 16 bits accumulate, it looks up the matching character in the primary repertoire and appends it. If the input has an odd number of bytes, the final 8 bits are emitted from a secondary 256-character repertoire. Because 8 divides 16 evenly, there is no padding and no padding check on decode.
Decoding maps each character back to its 16-bit (or trailing 8-bit) value and reassembles the byte stream. A secondary character appearing anywhere except the end is reported as an error, as is any character outside the repertoire. The tool then decodes the bytes as UTF-8 to give you back the original text.
How Base65536 works
Base65536 was created by qntm as a Unicode analogue of Base64. Where Base64 uses 64 ASCII symbols to encode 6 bits each, Base65536 uses 65,536 Unicode code points to encode 16 bits each. The name reflects the repertoire size. On a UTF-16 platform, each output character occupies one 16-bit code unit, so the encoding achieves 2 bytes per character, compared with Base64's 0.75 bytes per character.
The repertoire is built from carefully chosen Unicode blocks. The original specification avoids surrogate pairs (code points U+D800 to U+DFFF), control characters, and code points that some systems strip or normalize. A quirk of the original implementation is that the primary repertoire bytes are stored in a swapped order, which the reference encoder preserves for backward compatibility. This tool follows that same byte ordering so output is interoperable with the reference library.
The trade-off is portability. On a UTF-8 transport, each BMP character costs up to 3 bytes and supplementary-plane characters cost 4 bytes, so the byte footprint can exceed Base64. Base65536 wins only when the transport counts characters or stores UTF-16. For a slightly more portable variant that stays within the BMP, see Base32768. For a character-counted variant, see Base2048.
How to use this tool
- Type or paste your text into the input field.
- Keep the mode on Encode to produce Base65536, or switch to Decode to recover the original text.
- The output updates live. Copy it with the copy button.
- On decode, paste Base65536 text. Whitespace is ignored; unknown characters raise an error.
- Use Swap to feed the output back as input and flip the mode in one click.
Real-world examples
Storing a key fingerprint in a JSON string field
A backend stores a 32-byte SHA-256 fingerprint in a JSON column that is typed as a UTF-16 string. Base64 would need 44 characters. Base65536 needs 16 characters, cutting storage and index size. The team decodes with the same tool when they need the raw bytes for comparison.
Compacting a CTF flag for a Unicode channel
A Capture The Flag challenge wants players to submit a 64-byte token through a chat system that handles full Unicode. Encoding the token with Base65536 produces 32 characters, short enough to read at a glance. Players paste it into the decoder to verify they have the right bytes before submitting.
Recovering from a normalization accident
A user pastes Base65536 output into a rich-text editor that applies Unicode normalization (NFC). Some repertoire code points are reordered or combined. On decode the tool reports `Unrecognised Base65536 character`, which tells the user the editor mangled the string and they should paste as plain text instead.
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 | Maximum UTF-16 density |
Limitations or considerations
Base65536 is an encoding, not encryption, and provides no confidentiality. Its density advantage depends on the transport. On UTF-8 channels the byte footprint can be larger than Base64 because each character may take 3 or 4 bytes. The repertoire includes supplementary-plane code points, so systems that strip non-BMP characters will break the output. Unicode normalization (NFC, NFKC) can also corrupt the string. Use it only on transports known to preserve code points verbatim.
Frequently asked questions
Why is Base65536 called that when Unicode has 1,114,112 code points?
The repertoire is restricted to 65,536 code points chosen for safety and to fit exactly 16 bits per character. Using the full code space would require handling surrogate pairs and would break on systems that cannot represent supplementary-plane characters, defeating the goal of UTF-16 compatibility.
Is Base65536 output always half the length of the input bytes?
For even-length input, yes: each pair of bytes maps to one character. For odd-length input, the final byte maps to a secondary character, so the output is ceil(byteLength / 2) characters. There is no padding.
Will Base65536 survive being sent through Twitter or a chat app?
Not reliably. Some platforms strip or normalize the supplementary-plane code points in the repertoire. Base65536 is designed for UTF-16 storage and faithful Unicode transports. For character-counted platforms that may mangle non-BMP characters, Base2048 is safer because it stays within the BMP.
How does Base65536 compare to Base32768?
Base65536 encodes 16 bits per character and uses supplementary-plane code points. Base32768 encodes 15 bits per character and stays within the BMP, making it more portable at a small density cost. Choose based on whether your transport handles non-BMP characters.
Conclusion
Base65536 reaches the theoretical density ceiling for Unicode-clean binary encoding on UTF-16 systems: two bytes per character, no padding. It is the right choice when storage is measured in characters and the transport preserves the full Unicode code space. Encode a payload above and compare the length with Base64. If you need BMP-only output, try Base32768 next.