Introduction
Need to squeeze binary data into a system that counts characters instead of bytes? Base2048 was built for exactly that constraint. It packs 11 bits into every output character drawn from a 2048-code-point Unicode repertoire, so a payload travels through Twitter, Discord, or any Unicode-clean channel in fewer visible characters than Base64. This tool encodes text to Base2048 and decodes it back, entirely in your browser. Paste your input above, switch the mode, and the result appears instantly. No data leaves your device.
What this tool does
- Encodes UTF-8 text into Base2048 using the qntm 2048-code-point repertoire, emitting 11 bits per primary character.
- Decodes Base2048 back to the original UTF-8 text, validating the padding bits and rejecting unrecognised characters.
- Handles the trailing bits correctly using the secondary 3-bit repertoire so round-trips are lossless for any byte length.
- Strips whitespace on decode so pasted output with line breaks still parses.
- Runs entirely client-side with no server calls, so binary payloads never leave the browser.
How this tool works
The tool takes your input string, converts it to UTF-8 bytes, and walks the bit stream most-significant-bit first. Every time 11 bits accumulate, it looks up the corresponding character in the primary repertoire and appends it to the output. When the input length is not a multiple of 11 bits, the final partial group is padded with 1s and emitted from a smaller 8-character secondary repertoire, which is what makes Base2048 lossless for any byte count.
Decoding reverses this. Each character maps back to a number of bits (11 for primary characters, 3 for the trailing secondary character) and a value. The tool reassembles the byte stream, verifies that the padding bits are all 1s, and throws a clear error if a character is outside the repertoire or if a secondary character appears before the end. Whitespace in the pasted input is ignored on decode.
How Base2048 works
Base2048 is one of several binary-to-text encodings designed by qntm to use the Unicode code space instead of the ASCII subset that Base64 and Base85 rely on. The motivation is efficiency on platforms that measure length in characters rather than bytes. Base64 encodes 6 bits per character. Base2048 encodes 11 bits per character, so a 256-byte payload needs roughly 187 Base2048 characters versus 342 Base64 characters.
The repertoire is a curated set of 2048 Unicode code points chosen to be safe on Twitter and in other Unicode-clean systems. The selection avoids surrogate pairs, control characters, combining marks, and code points that some platforms normalize or strip. A separate 8-character repertoire handles the final 1 to 3 trailing bits so no padding character is needed and the encoding is self-delimiting.
Because the output uses non-ASCII characters, the storage advantage only holds on systems that handle Unicode faithfully. If the transport re-encodes to UTF-8, each Base2048 character may take up to 3 bytes, and the byte-level advantage disappears. For UTF-16 systems (JavaScript, Java, Windows) each Base2048 character is one 16-bit code unit, which is where the format shines. For maximum byte-level density on UTF-16 transports, see Base65536 and Base32768.
How to use this tool
- Type or paste your text into the input field.
- Keep the mode on Encode to produce Base2048, or switch to Decode to recover the original text.
- The output updates instantly as you type. Copy it with the copy button.
- On decode, paste Base2048 text. Whitespace is ignored, but unknown characters raise an error.
- Use Swap to move the output into the input and flip the mode in one click.
Real-world examples
Sharing a binary blob on a character-limited platform
A developer needs to post a 128-byte Ed25519 public key in a Discord message and wants it short. Encoding the key with Base64 produces 172 characters. Encoding it with Base2048 produces 94 characters, well under common message limits. The recipient pastes the string into the decoder, recovers the raw bytes, and imports the key. Because the output is Unicode, the channel must preserve code points faithfully.
Round-tripping UTF-8 with multibyte characters
Input `Hello 世界 😀` (which mixes ASCII, a CJK ideograph, and an emoji) encodes to a compact Base2048 string. Decoding it back yields the exact original bytes, including the 4-byte emoji sequence. The tool handles arbitrary UTF-8 because it operates on the byte stream, not on individual characters.
Detecting corrupted output
Someone copies a Base2048 string through a system that silently replaces unsupported characters with U+FFFD. On decode, the tool reports `Unrecognised Base2048 character` and names the offending code point, making it clear that the transport corrupted the payload rather than the encoding being wrong.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Base64 | 6 bits/char, ASCII | Email, JWTs, data URIs (RFC 4648) |
| Base85 / Ascii85 | ~6.4 bits/char, ASCII | PDF, IPv6, ZeroMQ |
| Base2048 | 11 bits/char, Unicode | Character-counted channels (Twitter) |
| Base32768 | 15 bits/char, Unicode | UTF-16 storage (JS, Java) |
| Base65536 | 16 bits/char, Unicode | Maximum UTF-16 density |
Limitations or considerations
Base2048 is an encoding, not encryption. It provides zero confidentiality: anyone with the tool can decode it. The character-count advantage only materialises on transports that count characters and preserve Unicode code points. On a UTF-8 transport, each output character can take up to 3 bytes, so the byte footprint may be larger than Base64. Some platforms strip or normalize the code points in the repertoire, which breaks round-trips. Do not use Base2048 to hide sensitive data; pair it with a real cipher if confidentiality is required.
Frequently asked questions
Is Base2048 a standard like Base64?
No. Base64 is standardised in RFC 4648, but Base2048 is a community encoding created by qntm. It has a precise specification and reference implementation, but no IETF RFC. Interoperability depends on both sides using the same repertoire.
Why does my Base2048 output look like random Chinese and Devanagari characters?
The repertoire draws from many Unicode blocks including CJK ideographs, Devanagari, and others chosen for platform safety. The output is not meant to be human-readable. It is a compact binary representation that happens to use those code points.
When should I use Base2048 instead of Base65536?
Use Base2048 when the transport counts characters and may not handle supplementary plane characters well, since Base2048 stays within the BMP. Use Base65536 for maximum density on a UTF-16 system that handles the full code space.
Can Base2048 handle binary data that is not valid UTF-8?
This tool accepts text and encodes its UTF-8 bytes. If you have arbitrary binary data, encode it to bytes first. The underlying algorithm works on any byte sequence, but the tool's input is a text field.
Conclusion
Base2048 fills a specific niche: compact binary transport through character-counted, Unicode-clean channels. It trades ASCII compatibility for density, packing 11 bits into each character. Try encoding a short payload above and compare the length with Base64 to see the difference. For even denser UTF-16 storage, move on to Base32768 or Base65536.