Base58 Encoder / Decoder

Encode and decode data using Base58 (Bitcoin) or Base58Check with checksum validation.

Tested tool guide Tested browser tools Checked August 15, 2026

What Base58 Encoder / Decoder does, with a checked example

This tool converts raw bytes or text into a Base58 string, or decodes a Base58 string back into bytes. Base58 uses a 58-character alphabet that omits 0, O, I, and l so visually similar characters aren't confused when copied by hand - the scheme legacy Bitcoin addresses and WIF private keys use (native SegWit and Taproot addresses use Bech32/Bech32m instead, which this tool doesn't handle). What trips people up: leading 0x00 bytes aren't dropped, each becomes a leading '1' in the output, so decoding must account for it or the byte length comes out wrong. The Base58Check variant adds a version byte and a 4-byte checksum, letting the tool flag a mistyped or corrupted string instead of silently returning different bytes.

Worked example

A concrete input and expected output from the current implementation.

Input

Expected output

2g

The single byte 0x61 (97 decimal) is treated as a base-256 number and converted to base 58: 97 = 1x58 + 39, so the digits 1 and 39 map to '2' and 'g' in the Base58 alphabet, with no leading '1' since there's no leading zero byte.

How the result is produced

Encoding: base-256 to base-58

The input byte string is treated as one large base-256 integer and repeatedly divided by 58; each remainder maps to one alphabet character. Division yields the least-significant digit first, so the remainders are collected in that order and then reversed so the output reads most-significant digit first. Any leading 0x00 bytes in the input become leading '1' characters in the output rather than being consumed by the division, which preserves the original byte length on decode.

Base58Check: version byte plus checksum

Base58Check mode prepends a one-byte version/prefix to the payload, appends the first 4 bytes of double SHA-256 over that combination, then Base58-encodes the whole thing. Decoding reverses this, recomputes the checksum, and compares it to the trailing 4 bytes - a mismatch means checksum validation failed, which often points to a mistyped or corrupted string but can also just mean the input wasn't Base58Check-encoded at all (plain Base58, or data using a different checksum convention).

Good uses

decoding a legacy (Base58Check-encoded) Bitcoin address or WIF private key to inspect its version byte and raw payload bytes - Bech32 and Bech32m addresses (native SegWit, Taproot) aren't Base58 and this tool can't decode them
encoding a hash, public key, or other binary blob into a compact string that avoids visually ambiguous characters when copied or pasted by hand
checking whether a Base58Check string someone sent you has a valid checksum before trusting it was typed correctly

Limits and checks

Plain Base58 (no Check) has no error detection - a single wrong character decodes to a different, equally normal-looking byte string with no warning.
Leading zero bytes become leading '1' characters and count toward output length; adding or dropping a leading '1' changes the decoded byte count, not just the value.
A valid Base58Check checksum makes undetected accidental corruption very unlikely, but doesn't strictly prove the string is uncorrupted - a small fraction of corrupted byte strings will coincidentally still end in a valid 4-byte checksum. It also says nothing about whether the version byte matches the format (address, private key, or something else) you expect.

Common questions

Why does Base58 skip the characters 0, O, I, and l?

Those look alike in many fonts (zero vs. capital O, capital I vs. lowercase l vs. digit 1), and Bitcoin addresses are often copied by hand from a screen or printout. Excluding them removes that source of transcription errors; it doesn't change the underlying data, only which symbols represent it. Base58 is still case-sensitive - dropping those four characters is purely about visual distinction, not about upper vs. lower case, which remain significant and indistinguishable if the string is read aloud without stating case.

Can I decode any Base58 string using Base58Check mode?

No. Base58Check mode expects the last 4 bytes of the decoded payload to be a valid double-SHA-256 checksum of the preceding bytes. Feed it plain Base58 output that wasn't built with a checksum and the comparison will almost always fail, since only about 1 in 4 billion random byte strings coincidentally end in a valid checksum - so the tool will almost certainly report an invalid checksum rather than returning bytes.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.