Bitcoin Base58 is a 58-character alphabet of 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz that omits the visually ambiguous 0, O, I, and l, and decoding it returns the exact underlying byte sequence — no checksum, no padding, no secret. The alphabet splits into nine digits (1 through 9), twenty-four uppercase letters (A through Z excluding I and O), and twenty-five lowercase letters (a through z excluding l), giving exactly 58 symbols used as positional digits in base-58 arithmetic. To decode a Base58 string, count one leading 0x00 byte for every leading "1" symbol, treat the remaining characters as base-58 digits, convert that numeric value to base 256, and read the result as big-endian bytes. Hexadecimal is the lossless view because not every byte sequence decodes to valid UTF-8. Running the conversion through the Base58 Encode / Decode tool enforces this rule locally: any input containing whitespace, punctuation, or characters outside the Bitcoin alphabet is rejected instead of being silently cleaned, so a clean copy and paste is the fastest way to verify an unknown string.
Bitcoin Base58 Alphabet at a Glance
The Bitcoin Base58 alphabet is a single fixed string of 58 characters, and knowing where the excluded characters fall in ASCII makes it easier to spot typos and to recognize when a "Base58" string is actually something else. The table below breaks the alphabet into its three sections.
| Section | Characters | Count | Excludes |
|---|---|---|---|
| Digits | 123456789 | 9 | 0 |
| Uppercase | ABCDEFGHJKLMNPQRSTUVWXYZ | 24 | I and O |
| Lowercase | abcdefghijkmnopqrstuvwxyz | 25 | l |
Letter case is significant: z (index 57, value 57) and Z (index 32, value 32) are different digits, and any decoder that lowercases input first will produce wrong bytes. The four excluded characters each have a visually similar partner — 0/O and I/l — which is the reason they were dropped. Trailing whitespace, line breaks, and any punctuation outside this alphabet cause the raw decoder to reject the input rather than guess.
Cross-check the alphabet against the official Bitcoin Core base58 test vectors and the independent libbase58 reference when you need to confirm a tool is using the canonical order rather than a near-relative such as Flickr's Base58.
How to Decode a Base58 String with the Tool
The fastest decode path is to use the browser-based decoder, which handles alphabet validation, base conversion, and hex rendering for you. Follow these steps for a clean round trip.
- Open the Base58 Encode / Decode tool and select the Base58 to bytes and text mode.
- Paste the raw Base58 string exactly as you received it, with no surrounding whitespace, no newline at the end, and no copy-paste punctuation.
- Run the decoder. The page will reject any character that is not in 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz.
- Read the hex bytes output. This is the authoritative lossless result and is always shown as lowercase hexadecimal.
- If the bytes form valid UTF-8, the text interpretation panel shows the same payload as readable characters. If the bytes are not valid UTF-8, the text panel is hidden and only the hex view remains — that is the correct outcome, not an error.
- Compare the hex bytes against the format you expect (address, WIF, hash, opaque key). If the source called the value Base58Check, an address, or a versioned key, remember that this tool only proves raw byte conversion and does not validate the surrounding protocol.
For a guided walkthrough with worked strings and one-click results, see Decode Base58 Strings Back to Readable Data in One Click.
The Leading-Zero Rule
Bitcoin Base58 was designed to encode binary data — including payloads that begin with one or more 0x00 bytes — as a printable string. A naive integer conversion would drop those leading zeros and produce a different (and incorrect) byte sequence. The Bitcoin alphabet preserves them with a single rule: every leading 0x00 byte becomes a leading 1 symbol in the output, and every leading 1 in the input decodes back to a 0x00 byte.
Worked examples using the Bitcoin Core vectors:
- The single byte [0x00] encodes to "1": one leading 1 and no significant digits.
- The two bytes [0x00, 0x01] encode to "12": one leading 1 for the zero byte, then the value 1 rendered in base 58 as the index-1 digit 2.
- The two bytes [0xFF, 0xFF] encode to "LUv": no leading 1, because there are no leading zero bytes.
When decoding "12", the decoder first counts one leading 1 and emits one 0x00 byte, then converts the remaining digit 2 (value 1) to the byte 0x01. The byte sequence 00 01 is restored exactly. This is the rule that lets a Bitcoin address or a WIF key survive the trip through copy-paste, font swaps, and OCR without losing its leading version byte.
If you paste a string with several leading 1s and the decoder returns a short hex result, that is the leading-zero rule working correctly, not a bug.
Hex Output vs UTF-8 Text
Base58 is fundamentally a binary encoding. Even after the base conversion is correct, the recovered bytes may or may not happen to be valid UTF-8 — there is no guarantee either way. The decoder handles the two cases deliberately so the result is always verifiable.
When the bytes form valid UTF-8, both panels are shown and they match byte for byte: the hex view is the lossless encoding of the same characters the text panel displays. When the bytes are not valid UTF-8, the text panel is hidden with a clear note that the text interpretation is unavailable, and only the hex view remains. This split is intentional. Inserting Unicode replacement characters (U+FFFD) when the bytes are not valid UTF-8 would make the text panel appear to round-trip cleanly while silently changing the data.
Strings you would expect to be valid UTF-8 include short English phrases, JSON, and most protocol envelopes. Strings you should expect to be binary include raw public keys, signature bytes, encrypted ciphertext, and most hash digests. Treat the hex as authoritative in every case.
Base58 vs Base58Check vs Base64
Base58 is one of several common encodings you will meet when working with Bitcoin, IPFS, or other identifier formats. Picking the right decoder depends on which one your input actually uses.
| Property | Base58 (Bitcoin) | Base58Check | Base64 (RFC 4648) |
|---|---|---|---|
| Symbol set | 58 alphanumerics, no 0/O/I/l | Same 58 + a leading version byte | A–Z, a–z, 0–9, +, / |
| Padding | None | None | = characters |
| Checksum | None | 4-byte double-SHA-256 appended | None |
| Case-sensitive | Yes | Yes | Yes |
| Encodes raw bytes | Yes | Yes (with checksum) | Yes |
| Validated by this tool | Yes (raw) | No — use a wallet or reviewed library | No — use a Base64 decoder |
Base58Check is what Bitcoin addresses, WIF private keys, and extended public/private keys actually use on the wire: a one-byte version prefix, the payload, then a four-byte checksum. The raw decoder here can extract the bytes from a Base58Check string, but it will not tell you whether the checksum matches or whether the version byte corresponds to a real network. For those checks, route the value through a format-aware tool — the raw decode is just the first step.
If you need a non-Bitcoin alphabet or want padding-style output, swap to Base64 Encode / Decode for binary-to-text work or Base32 Encode / Decode for the canonical RFC 4648 variant.
Common Decoding Pitfalls
Most failed decodes come from one of four sources, all of which a raw decoder will surface as a clear rejection rather than a wrong answer.
- Stray whitespace or newline. Many wallets, block explorers, and APIs return a Base58 string with a trailing \n from JSON formatting. Strip it before pasting.
- Quotation marks or copy-paste artifacts. Wrapping characters from "…", smart quotes, or angle brackets will all be rejected because they are outside the alphabet.
- Visually similar substitutions. A 0 (zero), O (uppercase o), I (uppercase i), or l (lowercase L) in the input is almost certainly a typo, since the real alphabet never contains them. Compare against the source.
- Treating Base58Check as raw Base58. A Bitcoin address or WIF key decoded as raw Base58 will return bytes that look plausible but fail the checksum when verified. Always run Base58Check values through a checksum-aware verifier before trusting them.
If you suspect the input is Base64 instead of Base58 — for example, because it contains + or /, or ends with one or two = characters — switch to the Base64 decoder. The two alphabets overlap heavily on letters and digits, but the symbols and padding are different, and the alphabets cannot be substituted for each other.
If you're weighing options, Base64 Decode Example: From 'Hello' to an Emoji covers this in detail.