How to use it
- Choose a Format, and choose Encode or Decode under Mode.
- Type the text into Text. The result appears as you type.
- Read Check. When it says the text is not valid, fix the characters it names; when it is valid, copy the Result.
The five formats
Each format writes binary data with a fixed set of printable characters. The formats differ in how many characters they use, and in how much longer the output is than the input.
- Base32 (RFC 4648 section 6) uses A to Z and 2 to 7. Five bits go into each character, so eight characters hold five bytes, and the text is padded with = to a multiple of eight.
- Base32hex (RFC 4648 section 7) uses 0 to 9 and A to V. It keeps the sort order of the data, which Base32 does not.
- Base58 uses the Bitcoin alphabet, which leaves out 0, O, I and l so that similar characters are not confused. Each leading zero byte becomes a 1, and there is no padding.
- Ascii85 writes four bytes as five characters from ! to u, which is about a quarter longer than the data. Four zero bytes are written as z.
- Z85 is a version of Ascii85 designed for source code: four bytes become five characters from an 85-character alphabet that is safe in strings. Its data must be a multiple of four bytes.
Text and bytes
The text is encoded as its UTF-8 bytes (RFC 3629), so a letter such as ğ takes two bytes and an emoji takes four. Decoding turns the bytes back into text. When the decoded bytes are not valid UTF-8, for example a file or a key, the page shows them in hexadecimal instead, so no byte is lost.
What decoding accepts and rejects
RFC 4648 section 3.3 says a decoder must reject characters outside its alphabet. This page does the same, so Base32 accepts no lower-case letters. It ignores spaces and line breaks, because they come from copying and pasting. Base32 padding is optional. The page also rejects a Base32 text whose last character has pad bits that are not zero, which section 3.5 allows a decoder to do.
Worked example: foobar in Base32
The text foobar is six bytes. Base32 writes it as 16 characters, MZXW6YTBOI followed by six = signs, which is the value RFC 4648 section 10 gives for BASE32("foobar").
The table below is what the page shows for foobar in Base32, when Mode is Encode.
| Output | For foobar |
|---|---|
| Check | Encoded as Base32. |
| Result | MZXW6YTBOI====== |
| Bytes | 6 |
| Characters | 16 |
Frequently asked questions
Is Base32 a kind of encryption?
No. Base32 only writes the same bytes with a different alphabet. Anyone can decode it with no key, so it hides nothing and should not be used to protect data.
Why does Base58 leave out 0, O, I and l?
The Bitcoin alphabet, which the page uses, leaves out the characters that look alike in many fonts, so a value copied by hand is less likely to be read wrongly. The alphabet is in the Bitcoin Core source code.
Why is my Z85 text rejected?
Z85 encodes four bytes at a time, so the data must be a multiple of four bytes. When decoding, the text must be a multiple of five characters, and every character must be in the Z85 alphabet. A missing or extra character is the usual cause.
Why do I see hexadecimal instead of text?
The decoded bytes are not valid UTF-8 text. Showing them as text would lose or change some bytes, so the page shows every byte in hexadecimal.
Is Ascii85 the same as Base85?
Ascii85 is one version of base 85, with the characters ! to u and the z shortcut. Z85 is another base 85, derived from Ascii85, with a different alphabet that is safe in source code.
Is my text sent anywhere?
No. The encoding and decoding run in your browser, and nothing you type is sent to our server or stored there.
Sources
- RFC 4648: The Base16, Base32, and Base64 Data Encodings
- RFC 3629: UTF-8, a transformation format of ISO 10646
- Z85: ZeroMQ RFC 32, the Z85 encoding
- Bitcoin Core source, src/base58.cpp (the Base58 alphabet)
- Ascii85, Wikipedia (the Ascii85 encoding)
Figures and text last checked on Tuesday, November 10, 2026.