Base58 Encoder/Decoder – Encode Hex, Text and Base58Check
Developers working with crypto addresses, IPFS content IDs, or short opaque tokens meet Base58 whenever a value has to survive being read aloud or retyped from a chat window. This page encodes hex, UTF-8 text, or raw bytes into Base58 and decodes the reverse, with an optional Base58Check pass that adds a version byte and a SHA-256 checksum.
How It Works
The alphabet of 58 symbols uses digits 1 through 9, uppercase letters, then lowercase, skipping the four characters people confuse most: 0, O, I, and l. Encoding counts leading zero bytes, folds the remaining bytes into one BigInt, and repeatedly takes the remainder modulo 58, mapping each remainder to a symbol in the chosen table. Each leading zero byte prepends one copy of the alphabet's first character so the byte survives. Decoding reverses the steps: leading 1s become zero bytes, every character is looked up in the table, and an unknown character stops the run with an error naming it. Text input converts with UTF-8; even-length hex input parses into raw bytes first.
Base58Check adds a one-byte version prefix (0x00 for P2PKH, 0x05 for P2SH), computes SHA-256 twice over the versioned payload, and appends the first four digest bytes as a checksum. Decoding splits the trailing four bytes off, recomputes the double hash, and flags a mismatch. Check paths run as promises because WebCrypto digests are asynchronous.
Before and After
hex input: 0000ff
bytes: [0x00, 0x00, 0xff]
leading zeros: 2
base58: 115Q
decode: 0000ff (round trip matches)base58Decode("Cn8eVZg!")
error: Character "!" is not part of the
selected Base58 alphabet. (index 7)
base58CheckDecode("1kA3B35AUCmW")
error: Checksum mismatch: the decoded
value failed the double-SHA256
Base58Check test.Use Cases
| Developer | Production | Workflow |
|---|---|---|
| Reproducing a Bitcoin address bug from a key hash | Encoding P2PKH and P2SH payloads in wallet code | Paste hex, enable Base58Check, compare |
| Inspecting multihash bytes inside an IPFS CIDv0 | Serving content-addressed assets with a Base58 identity | Decode the Qm string, read codec prefix |
| Building short identifiers for URLs or tickets | Storing Solana public keys as Base58 text | Encode random bytes, test copy-paste |
Common Mistakes and Troubleshooting
- Treating Base58 like Base64. A Base64 string can contain 0, O, I, l, or an equals sign; a Base58 decoder fails on the first one.
- Pasting UTF-8 text where hex was expected. abcdef is valid hex, so the tool reads three bytes rather than six letters; hello and 68656c6c6f both encode to Cn8eVZg.
- Enabling Base58Check for a string that has no checksum. A plain address or CID fails the four-byte check even though the original value is fine.
- Assuming whitespace inside the string is harmless. Edges are trimmed, but a middle space is an out-of-alphabet character.
- Stripping leading 1 characters before decoding. Each leading 1 is a 0x00 byte, so trimming them loses data.
- Matching the wrong alphabet between systems. Ripple reorders case, so a Bitcoin string decoded as Ripple errors or yields other bytes.
Best Practices
- Pick the alphabet your ecosystem uses, name it in code review, and store it beside the encoded value.
- Wrap any identifier you invent in Base58Check with a deliberate version byte; the checksum catches typos before a value reaches a ledger.
- Keep test vectors in CI. Hex 0000ff must encode to 115Q and hello to Cn8eVZg.
- Store the original bytes and encode only at the boundary where a human-facing string is needed.
- Avoid uppercase-only transcription. Base58 is case-sensitive, and folding case destroys the value.
- Pair this decoder with a hex dump when an address fails on chain; comparing version, payload, and checksum narrows the fault.
Frequently Asked Questions
What is Base58 and how does it differ from Base64?
Base58 is a binary-to-text alphabet with 58 symbols picked so people can retype strings without hitting look-alike characters. It removes four troublemakers: zero, capital O, capital I, and lowercase l. Base64 uses 64 symbols plus padding, so its output contains those dropped characters.
Does encode mode treat my input as text or hex?
The tool inspects the trimmed input first. When every character is a hex digit (an optional 0x prefix is allowed) and the length is even, the value encodes as raw bytes; anything else converts to UTF-8. Typing 68656c6c6f and hello produce the same output.
What does the Base58Check option add?
Base58Check prepends a version byte, appends a four-byte checksum, and encodes the whole thing. The checksum is the first four bytes of a double SHA-256 over the versioned payload, computed with WebCrypto, so the path runs asynchronously.
Which alphabet variants are available?
Three alphabets ship with the tool: bitcoin, flickr, and ripple. Bitcoin is the default, with digits, uppercase letters, then lowercase minus the ambiguous characters. Flickr reorders case. Ripple starts with lowercase r, so XRP addresses begin with r.
Why do leading zero bytes become the character 1?
A zero byte adds nothing to the numeric value, so a plain base-58 conversion would lose it. The encoder counts leading zero bytes, converts the rest, and prepends one 1 for each, which is why hex 0000ff encodes to 115Q. Decoding applies the reverse rule.
Where is Base58 used in production?
Bitcoin and most UTXO-chain addresses are Base58Check strings, and older IPFS CIDs use Base58 for the multihash portion. Solana public keys are Base58-encoded 32-byte values without a checksum. Short URL identifiers borrow the alphabet because the strings survive chat apps better than hex.
What errors can decoding produce?
An unknown character stops the decode immediately and the message names it, for example Character "0" is not part of the selected Base58 alphabet. The page also appends the character position so you can find typos in long strings. Base58Check decode flags checksum mismatches.