Base58 / Base62 / Base100 Encoder and Decoder

Features

• Four encodings: Base58 (Bitcoin), Base58 (Flickr), Base62 and Base100
• Both Base58 alphabets — they are incompatible, and the same data encodes to entirely different strings
• Base100 follows the stek29 specification: each byte maps to one emoji in U+1F3F7–U+1F4F6
• Non-ASCII text handled as UTF-8 bytes, matching Bitcoin wallets and other implementations
• Leading zero bytes are preserved — a Bitcoin address begins with 0x00, and dropping it changes the address
• A character outside the alphabet is reported by name instead of being dropped
• ⚠️ Also generates correctly formatted Bitcoin addresses (mainnet / testnet, P2PKH / P2SH) for test data. Nobody holds the private keys for these, so they are for fixtures only

How to use

1. Choose the direction: encode or decode
2. Choose the encoding (Base58 has two alphabets — pick the right one)
3. Paste your content; the result appears as you type
4. Click Copy to take the result

FAQ

Why does Base58 leave out 0, O, I and l?

Because its audience is a human comparing an address against a screen. In most fonts 0 and O are hard to tell apart, and so are l and I. Misread one character in a Bitcoin address and the funds go to an address that either does not exist or belongs to someone else, with no way to reverse it. Four fewer characters costs about 3% in length and removes an entire class of human error. It is why Bitcoin addresses never contain those two digits or those two letters.

How do the Bitcoin and Flickr Base58 alphabets differ?

Only in where the uppercase letters sit: Bitcoin puts them first (123456789ABC…abc…), Flickr puts them last (123456789abc…ABC…). Neither contains 0, O, I or l. They are incompatible — decode a string with the wrong table and you get entirely different bytes, silently, with no error. Confirm which table the other side uses before you rely on it.

What is Base100, and why is the output longer?

Base100 maps every byte to a fixed emoji (byte n becomes code point U+1F3F7 + n). It is fixed-length, one character per byte, with no base conversion involved. Output therefore always grows: a byte takes 3–4 bytes in UTF-8, and the emoji adds its own bytes on top. It is neither compression nor encryption — its purpose is turning data into something that looks like emoji to a filter that only accepts printable characters.

Decoding says the bytes are not valid UTF-8 text

That means the encoded string carries binary rather than text. Base58 is most often used on binary data — a Bitcoin address holds a version byte, a public key hash and a checksum, none of which is meant to be read as text. The output here is a text box and cannot display binary, so it reports an error rather than handing you mojibake.

Why does decoding a Base58 string starting with "1" produce extra bytes?

Base58 is a big-integer representation, and big-integer notation swallows leading 0x00 bytes — [0x00, 0x41] and [0x41] have exactly the same numeric value. To round-trip correctly, the convention is that each leading 0x00 byte is written as one instance of the first alphabet character (which is "1" in the Bitcoin table). So every leading "1" stands for a real 0x00 byte, not padding. That mechanism is how Bitcoin addresses keep their version byte intact.

Can the generated Bitcoin addresses receive money?

No — and this needs to be unambiguous: coins sent to them are destroyed, and nobody can recover them. A real Bitcoin address is the HASH160 of a public key; here twenty random bytes are used as that HASH160 directly. Statistically that is indistinguishable from a real address, but the matching private key was never generated and nobody holds it. That leaves exactly one use: test data. When you need a correctly formatted address for a demo, a screenshot, documentation or a test fixture, a real address would publish a third party’s receiving address, whereas these are random and unowned. They never appear on the blockchain — they are just strings with valid format.

Why is there no SegWit bc1 address?

Because bech32 is not Base58. `bc1q…` uses a completely different algorithm: a different alphabet (32 characters, all lowercase) and a different checksum (a BCH code that can *correct* up to four mistyped characters, where Base58Check can only *detect* errors). Slipping it in among the Base58 variants would imply the encoding is interchangeable, when in fact swapping the alphabet produces something entirely different. Use a dedicated bech32 tool for SegWit. Note also that what this page generates is a Base58Check address (P2PKH / P2SH) — no mnemonic and no private key. It is an address, not a wallet.