About

Base58 encoding, introduced by Satoshi Nakamoto for Bitcoin addresses, deliberately omits visually ambiguous characters (0, O, I, l) from its 58-character alphabet. This prevents transcription errors in cryptocurrency wallets and check-based systems but makes the encoding incompatible with standard Base64 tooling. A mismatched decode - feeding Base58 into a Base64 decoder - silently produces corrupt byte streams, which can mean lost funds or broken cryptographic verification. This tool performs the intermediate step correctly: it decodes your input to raw bytes using arbitrary-precision integer arithmetic, then re-encodes to the target format with proper leading-zero preservation.

Base64 (RFC 4648) uses a 64-character alphabet plus = padding and is the standard for embedding binary data in JSON, email (MIME), and data URIs. The conversion is lossless in both directions provided the source string is valid. This tool validates every character against the respective alphabet before processing and reports the exact position of any illegal character. Note: this converts the encoding, not the semantics - a Base58Check string with a checksum byte will have that checksum preserved in the Base64 output, but it will not be independently verified here.

Formulas

Base58 decoding converts a string of length n over alphabet A₅₈ into an integer, then into a byte array. The integer value is computed as:

V = n−1∑i=0 d_i ⋅ 58ⁿ⁻¹⁻ⁱ

where d_i is the index of the i-th character in the Base58 alphabet (range 0 - 57). Leading 1 characters (index 0) represent leading zero bytes and are counted separately, then prepended as 0x00 bytes to the result.

The integer V is converted to bytes via repeated division:

V = b_k ⋅ 256^k + b_k−1 ⋅ 256^k−1 + … + b₀

Base64 encoding groups the resulting byte array into 3-byte (24-bit) blocks, each split into 4 groups of 6 bits, mapped to the Base64 alphabet. If the final block has fewer than 3 bytes, = padding is appended:

output length = 4 ⋅ ceil(byte count3)

where d_i = index of character in alphabet, V = decoded integer value, b_j = j-th byte (big-endian), n = input string length, k = number of output bytes minus 1.

Reference Data

Property	Base58	Base64
Alphabet Size	58 characters	64 characters + padding
Characters Used	`1-9 A-H J-N P-Z a-k m-z`	`A-Z a-z 0-9 + / =`
Excluded Characters	0, O, I, l	None (all printable ASCII used)
Padding	None	= (1 or 2 trailing)
Leading Zero Bytes	Encoded as leading 1s	Encoded naturally in bit stream
Efficiency (bits/char)	≈ 5.86	6.00
Size Overhead vs Raw	≈ 137%	≈ 133%
Checksum (Check variant)	Last 4 bytes (Base58Check)	Not defined by format
Primary Use	Bitcoin/crypto addresses, IPFS CIDs	MIME email, Data URIs, JSON payloads
Case Sensitive	Yes	Yes
URL Safe	Yes (no + or /)	No (+ and / need escaping)
Human Readable	High (no ambiguous chars)	Moderate
Inventor / Origin	Satoshi Nakamoto, 2009	RFC 4648, 2006 (MIME since 1996)
Encoding Process	BigInt division by 58	6-bit grouping of octets
Alphabet Order	Numeric → Uppercase → Lowercase (minus exclusions)	Uppercase → Lowercase → Digits → +/
Max Address Length (BTC)	34 characters (P2PKH)	N/A
Decode Complexity	O(n²) naive, O(n log n) optimized	O(n)

Frequently Asked Questions

These four characters are visually ambiguous in many typefaces: the digit 0 resembles uppercase O, and uppercase I resembles lowercase l. In cryptocurrency contexts, a single misread character in an address causes irreversible fund loss. Satoshi Nakamoto removed them to minimize human transcription errors when addresses are copied by hand or read aloud.

Yes, provided the input is a valid string in the source encoding. Both encodings are deterministic bijections between byte arrays and character strings. The tool decodes the source to its raw byte array, then re-encodes to the target format. Round-tripping (Base58 → Base64 → Base58) returns the original string exactly. The only caveat is Base58Check strings: the 4-byte checksum is preserved in the output, but this tool does not independently verify or strip it.

Base64 works on fixed 6-bit chunks aligned to byte boundaries, so it processes each character in constant time. Base58 requires arbitrary-precision integer arithmetic because 58 is not a power of 2. Each new character multiplies the accumulated value by 58 and adds, which for a naïve implementation means touching every digit of a growing big integer. For typical cryptocurrency addresses (25 - 35 characters), this is imperceptible. For very long inputs (thousands of characters), performance degrades quadratically.

In Base58, each leading 1 character (the first character in the alphabet, representing value 0) maps to exactly one 0x00 byte. This is a special convention: normal positional encoding would discard leading zeros. The tool counts leading 1s, strips them, decodes the remainder to a BigInt, converts to bytes, then prepends the corresponding number of 0x00 bytes before Base64-encoding the complete array.

Yes, but the tool treats the entire Base58 string as raw data. It will decode all bytes including the 1-byte version prefix and the 4-byte SHA-256d checksum suffix, then Base64-encode the full byte array. It does not validate or strip the checksum. If you need to verify address integrity, compute SHA256(SHA256(payload)) separately and compare the last 4 bytes.

The tool validates every character before attempting conversion. If an invalid character is found, it reports the exact character and its position in the string via an error message. No partial output is produced. For Base58, any occurrence of 0, O, I, or l is flagged. For Base64, any character outside A-Za-z0-9+/= is rejected, and padding placement is checked for correctness.