Security Runs locally Ready to use Built-in examples No tracking

Base58 Encoder / Decoder

Base58 drops the easily confused characters 0, O, I and l so the result can be copied by hand or read aloud. This tool follows the Bitcoin convention of encoding each leading zero byte as the character 1, and shows a hex view for binary payloads.

Copying a Bitcoin address to a friend should not involve an argument over whether that character is a zero or a capital O — Base58 exists for transcription and dictation, and drops the most confusable characters from the alphabet. Paste text or hexadecimal data to encode; decoding returns both a text and a hex view, and leading zero bytes are handled the Bitcoin way.

Two conventions catch people out. The first is leading zeros: a plain numeric conversion loses the zero bytes at the front, and Bitcoin specifies that each leading zero byte is encoded as a 1 — miss that rule and an address beginning with 1 decodes to the wrong number of bytes. The second is that Base58 has no built-in check, so a transcription error passes silently; Bitcoin addresses rely instead on the 4-byte checksum of the surrounding Base58Check. It is not encryption either.

—

—
—

How to use

  1. Paste the text or hexadecimal data to encode, or the Base58 string to decode.
  2. Choose the direction.
  3. Read both the text and the hex view.
  4. Remember leading zeros map to leading 1s, and that Base58 carries no checksum.

How it works

Why leading zero bytes become the character 1

Base58 works by "treating the byte string as one big integer, repeatedly dividing by 58 and keeping remainders" — but pure numeric conversion loses leading zero bytes, because numerically 0x00 is indistinguishable from "no byte here". Bitcoin's rule: each leading zero byte encodes to one character 1, and decoding restores each leading 1 to a zero byte. Without this rule, addresses starting with 0x00 (the version-byte-0x00 class, most famously addresses starting with 1) would decode short. This tool implements the rule on both sides.

When decoding yields hex, not text

Decode input isn't necessarily text. Base58-encoded private keys, hashes and binary key fragments may not map to legal UTF-8 characters at all. In that case the main result stays empty with a "non-text" note, while the hex result and byte count are shown — hex is the correct presentation for such data, not a tool malfunction.

Base58 vs. Base64 trade-offs

Compared with Base64, Base58 drops 6 characters (58 vs. 64) to make "0 vs. O" and "1 vs. l" unmistakable. The cost: about 4–5% more length, and no built-in error checking — Base58 itself doesn't detect transcription mistakes; Bitcoin addresses add a 4-byte checksum via Base58Check. Whether a mistyped address errors out depends on the target system, not this tool.

Code example

JavaScript Using the bs58 library in Node 

// npm install bs58
const bs58 = require("bs58");

bs58.encode(Buffer.from("hello"));   // encode
bs58.decode("Cn8eVZg");              // decode, returns a Buffer

// Bitcoin addresses use Base58Check (with a 4-byte checksum):
// the double SHA-256 checksum has to be computed separately — bs58 does not include it

Python The base58 library 

# pip install base58
import base58

base58.b58encode(b"hello")
base58.b58decode(b"Cn8eVZg")

# Leading zero bytes map to the character 1 under the Bitcoin rule — the library handles this

FAQ

What is the actual difference between Base58 and Base64?

Base64 uses 64 symbols (upper and lower case, digits, + and /) at 6 bits per character, inflating data by about a third; Base58 uses 58 symbols — it removes the easily confused 0, O, I and l plus two symbol characters — and does big-integer arithmetic per 8 bits, costing about 37% more. In short: Base64 is compact for machines; Base58 is legible for human copying and dictation.

Why are 0, uppercase O, uppercase I and lowercase l missing from Base58?

These four are the easiest to confuse in handwriting: 0 and O look nearly identical, and 1, I and l blur together. Bitcoin's early designers removed them from the alphabet, leaving 58 characters. So seeing a 0 or O in a supposed Base58 string means it was copied wrong.

Why do Bitcoin addresses often start with 1?

Legacy P2PKH addresses begin with the version byte 0x00, and each leading zero byte encodes to one character 1 — so such addresses necessarily start with 1, and the count of leading 1s reflects how many zero bytes follow. This also explains why decoding restores those zero bytes: skipping them yields the wrong byte count and fails address validation.

Can the encoded output be used as an encrypted string?

No. Like Base32 and Base64, Base58 is just another notation — no key, no confidentiality; anyone can restore it in one click. Its value is "fewer errors, easy to copy", not "hiding content". For secrecy use encryption (like this site's AES tool), and never paste a real private key into any online tool.

Why is encoding deterministic while AES encryption isn't?

Different goals. Encoding is a deterministic map — same input, same output — so the other end can restore it. AES generates a random salt and IV each run, so encrypting the same plaintext twice with the same password gives different ciphertexts — deliberately, to prevent attackers inferring "same plaintext" from "same ciphertext" and to defeat rainbow tables.

The decoded main result is empty and only hex shows — is it broken?

No. It means the decoded bytes aren't legal UTF-8 text — a private key, hash or compressed data — and can't be displayed as text. The tool detects this, marks it "non-text", and keeps the full hex result and byte count. For binary data, trust the hex.

Why does my decoded address have more bytes than expected?

Two common reasons: leading zero bytes were restored (they exist — encoding just compressed them into 1s), and a full Base58Check address carries a 4-byte checksum at the end. To confirm version bytes and checksum, use a dedicated Base58Check-aware tool.

Do spaces or newlines in the input affect decoding?

No. All whitespace is ignored during decoding, so strings transcribed in 8-character groups paste in directly. But visible characters outside the alphabet (0, O, I, l) trigger an invalid-character error — by design, since their presence in Base58 always signals a transcription mistake, and silently ignoring them would produce a wrong result.