Pick Encode or Decode, choose a scheme and click its action button. All processing stays in your browser.
What are Base32 and Base58?
They are two answers to one question: a channel that carries text is asked to carry bytes. Base32 and Base58 are not encryption and they are not hashing — they do not hide anything and they do not shorten anything. They rewrite a byte string using a fixed set of readable characters, and anyone who knows which set was used can turn it straight back. The only reason to prefer one over the other is what the receiving end does with the characters.
Two families do that rewriting in completely different ways, and the difference explains almost every surprise on this page:
- Bit packing — Base32, Base32 Hex, Crockford Base32, z-base-32. The bytes are cut into fixed groups and every five bits become one character. The output length is predictable from the input length, and the last, partly filled group is either marked with padding characters or left short.
- Big-number conversion — every Base58 table. The whole byte string is read as one enormous number in base 256 and written out again in base 58. There are no groups and no padding; the length does not divide into anything, and each leading zero byte becomes one leading zero symbol.
Where the six data-carrying bits go: Base32 spends five bits per character, so it needs eight characters for every five input bytes — about 60% larger. Base58 spends about 5.86 bits per character, so it lands near 37% larger. Base64 fits six bits per character and lands at 33%. Bigger alphabets are shorter and harder to read aloud, which is exactly the trade each one makes.
The seven alphabets on this page
Every alphabet is printed in full rather than described, because two tools that print different characters under the same name will not agree with each other no matter what the label says. The RFC 4648 rows are normative; the Crockford and z-base-32 rows follow what the format's author published; the three Base58 rows are widespread conventions rather than standards, which is why they are listed separately.
Crockford Base32 and the modulo 37 check symbol
The alphabet drops I, L, O and U so that no symbol can be read as another one. What is left is case-insensitive on the way in: i and l read as the digit 1, o reads as the digit 0, and hyphens exist only to make a long string easier to read. On top of that the format defines an optional check symbol, which is the value of the symbol string read as a base 32 number, taken modulo 37, and written with five extra symbols for the values 32 to 36.
The check symbol is computed over the symbol string, not over the bytes: because the encoder zero-extends the last group, decoding the same characters always returns to the same value. That is why the check value in the table can be reproduced by hand from the encoded column alone. The five extra symbols are *, ~, $, = and U for the values 32, 33, 34, 35 and 36, so a check symbol is not always a digit or a letter.
z-base-32
z-base-32 keeps the five-bit packing of RFC 4648 Base32 and only changes the order of the thirty-two characters. The order is chosen so that the characters a person is most likely to have to write down are the ones that are easiest to write and hardest to confuse. It has no padding, so a reader has to know how many symbols a value is expected to have; that is the price of a format designed to be read by hand first.
Base58Check: one version byte, the payload, four bytes of checksum
Base58 on its own has no way to tell a mistyped string from a correct one, because almost any combination of its fifty-eight characters is a valid number. Base58Check fixes that by putting the data inside a wrapper: one version byte, then the payload, then the first four bytes of SHA-256 applied to the first two parts twice in a row. A receiving program recomputes those four bytes and refuses the string when they differ. The version byte is what tells a wallet whether it is looking at a payment address, a script address or a private key.
The generator underneath the converter takes the version byte and the payload as hexadecimal and writes the Base58Check string; the verifier reads one back, splits off the four checksum bytes, recomputes them and reports both the one it found and the one it expected. A wrong checksum here means the string was mistyped or altered — it never means the payload itself is wrong, since the payload is never interpreted.
Common misunderstandings
- "Base64 is encryption." No. There is no key and no secret; the output is reversible by anybody. Base32 and Base58 are in the same position, and dragging a value through all three does not add protection either.
- "A Base58 string is a Bitcoin address." Only when it also passes the Base58Check checksum and carries a version byte the receiving software recognises. Base58 strings appear in many other places, including plain identifiers with no checksum at all.
- "The three Base58 alphabets are interchangeable." They use the same fifty-eight characters in three different orders, so the same bytes produce three different strings. A tool has to be told which one to use, and this page always says which one it used.
- "Padding is part of the value." The
= characters only mark the last group. Two Base32 strings that differ only in their padding describe the same bytes, which is why the decoder accepts a string with the padding cut off.
- "Any characters work." Each alphabet is a fixed set. A character from outside it has no value, so the decoder stops and names the character and its position rather than guessing.
Questions that come up
Why does Base32 use 2-7 and not 0-9? Because RFC 4648 chose the alphabet so that it stays inside the characters a domain name may contain, and so that it is easy to read aloud. Base32 Hex uses 0-9 A-V instead when natural sorting matters more.
Why does a Base58 string start with 1 so often? Each leading zero byte of the input becomes one leading 1 (the first character of the Bitcoin and Flickr alphabets). A version byte of 0x00 is one zero byte, so most mainnet Bitcoin addresses begin with exactly one 1.
What does the Sample button load? The example that belongs to the scheme and the direction currently on screen, never a fixed text. The encoder is given the text of the scheme's own example — the RFC 4648 section 10 vectors for Base32 and Base32 Hex, Crockford's 12345, the z-base-32 rows printed above — and the decoder is given the encoded string for the selected alphabet, which is what makes the sample usable in both directions. The three Base58 rows carry the same text on purpose, so switching the scheme and pressing Sample again shows the three orderings of the same fifty-eight characters side by side. With the Crockford check symbol ticked the decoder is handed the value with the symbol on the end, which is the only way to watch the verifier accept one.
Does this page send my data anywhere? No. Every conversion happens in this browser tab, and the page contains no network calls of any kind. That is also why it works with the file opened directly from disk.
Which one should I use for a secret? TOTP and HOTP authenticator secrets are usually Base32 in the RFC 4648 alphabet, because the secret has to be typed by hand. Use whichever one your receiving software asks for, and never rely on the encoding itself for secrecy.
