Base58 Encoder / Decoder

What Bitcoin Base58 encoding does

Base58 represents a byte sequence with fifty-eight alphanumeric symbols. This tool uses the alphabet popularized by Bitcoin: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz. It removes zero, uppercase O, uppercase I, and lowercase l because those characters are easy to confuse in many fonts. It also avoids punctuation that can be awkward in filenames, plain text, or copied identifiers.

Unlike Base32 and Base64, Base58 is not a fixed-width bit-group encoding. The byte sequence is interpreted as one large unsigned integer and repeatedly divided by fifty-eight. That approach would normally lose zero bytes at the beginning, so the format has a special rule: each leading zero byte is represented by a leading 1 character. A correct implementation must count those bytes before converting the remaining integer.

This page encodes normal text as UTF-8 bytes. During decoding it reverses the Base58 integer into bytes and uses a strict UTF-8 decoder. Base58 itself can carry any binary data, but a random key or transaction payload may not be readable text. The tool reports that boundary rather than replacing invalid byte sequences with the Unicode replacement character.

How to use the Base58 converter

1. Select Encode for ordinary text or Decode for an existing Bitcoin-alphabet Base58 string.
2. Paste the input exactly. Base58 has no whitespace, separator, or padding rule, and uppercase and lowercase characters are different digits.
3. Check the result immediately. An illegal symbol is reported with an error instead of being silently removed or substituted.
4. Use the Hello World vector to compare another implementation, or use a Unicode example to verify that both sides agree on UTF-8.
5. Swap the result back through the opposite direction. For binary payloads, use the exported byte functions in code rather than assuming every decoded sequence is text.

Bitcoin Base58 examples

The examples show text conversion, Unicode bytes, preserved zero prefixes, and invalid-character boundaries. Base58 has no padding, so the exact leading 1 characters are meaningful data.

Alphabet, leading zeros, and text limits

Encoding accepts Unicode text and does not add a checksum or version byte. Decoding accepts only the exact Bitcoin alphabet. There is no equals-sign padding and no permitted whitespace. A newline copied from a wrapped document is therefore an error, not decoration.

Leading 1 characters are significant. Each one contributes a zero byte before the integer-derived bytes. Removing a leading 1 changes the data even when the rest of the value stays the same. Conversely, a 1 that appears after another digit is simply the alphabet’s zero-valued digit inside the number; it is not treated as a prefix marker.

• The characters 0, O, I, and l are always invalid in the Bitcoin alphabet.
• Uppercase and lowercase symbols are not interchangeable.
• No padding is added or accepted.
• Every leading zero byte becomes exactly one leading 1.
• Decoded bytes must be valid UTF-8 for this text interface to display them.

How Base58 preserves a byte sequence

The encoder first counts zero-valued bytes at the start of the UTF-8 array. It then folds all bytes into a non-negative big integer by multiplying the current value by 256 and adding the next byte. Repeated division by 58 yields remainders from zero to fifty-seven; each remainder selects a character from the Bitcoin alphabet. Because remainders arrive least significant first, the characters are prepended or reversed before the zero-byte prefix is restored as 1 characters.

The decoder performs the mirror operation. Starting from zero, it multiplies by 58 and adds the value of each symbol. The resulting big integer is repeatedly split into base-256 bytes. Finally, it prepends one zero byte for every leading 1 in the original string. This explicit prefix step is essential for addresses, keys, hashes, and test vectors where fixed byte length matters.

JavaScript BigInt makes the arithmetic exact for long values, but it does not make Base58 self-validating. Any string made from the alphabet maps to some byte sequence. Applications that need typo detection often use Base58Check, which wraps payload bytes with version information and a checksum. This generic converter intentionally does not invent those protocol fields.

Where Base58 is used

Base58 is chosen mainly for human-facing identifiers whose underlying value is binary. Its benefits are readability and punctuation-free output, not compactness alone or security.

Base58 errors that matter

The most obvious error is an excluded character, but case changes and missing prefixes can be more subtle. A value copied through software that normalizes case is corrupted even though all remaining characters still belong to the alphabet. Base58 has no padding length that can expose the damage.

A syntactically valid value can decode to bytes that are meaningless for the protocol that produced it. This page knows the alphabet and UTF-8 text boundary; it does not know Bitcoin address versions, checksums, multibase prefixes, key lengths, or application-specific schemas.

• A copied 0 is not accepted as a substitute for the digit-like letter O; both are absent anyway.
• Whitespace and line wrapping must be removed by the user only when the source specification permits it.
• Deleting a leading 1 deletes a leading zero byte.
• Changing case changes the numeric value rather than merely changing presentation.
• A Base58Check string should be validated by a Base58Check implementation, not by this raw decoder alone.

Base58, Base58Check, and RFC encodings

Raw Base58 is only a reversible representation. Base58Check is a structured format that usually appends a four-byte checksum derived from double SHA-256 and may prepend a version byte. Decoding the alphabet is just one step in validating such a value.

Base32 and Base64 use fixed bit groups, making streaming and length calculation simple. Base58 produces a friendly alphabet but requires division of the full number or an equivalent base-conversion algorithm.