DevKitHub

Encoding & Conversion

Base58, Base32 and Base62 Encoder and Decoder

Encode or decode Base58, Base32, Base32hex, Base62 and hex. These are the encodings Base64 tools do not cover, and the ones several things you debug actually use.

Addresses, IPFS CIDv0, Solana keys.

1 line
1 line

This tool runs entirely in your browser. Your input is never uploaded, stored or logged.

How it works

Base64 is everywhere and these are not, which is inconvenient because they are what several things people debug are actually encoded in. A TOTP shared secret is Base32. A Bitcoin address, a Solana public key and an IPFS CIDv0 are Base58. A Tor v3 onion address is Base32. Needing to decode one has generally meant installing a library or pasting the value into an unknown page, which for a key is a poor trade.

Base58 exists for a specific reason worth knowing: it drops 0, O, I and l — the four characters people confuse when retyping — and drops + and / so a value selects as one word by double-click and survives a URL without escaping. It is not a bit-packed encoding like Base64 or Base32; it is arithmetic in base 58 over the whole input as one number, which is why its output length is not a neat function of its input length.

That arithmetic creates the trap this tool handles explicitly. Once the input is a single big number, leading zero bytes carry no value and vanish — so they are counted separately and re-emitted as leading "1" characters. That is why a Bitcoin address beginning with a zero byte starts with a 1, and why trimming those leading ones produces a different, valid-looking address belonging to nobody.

Common problems

Every example below is run against this tool in our test suite, so what it says here is what the tool actually does.

That is not a base58 character.

3vQB7B6MrGQZaxCuFg4oh0
Why:
Base58 deliberately excludes 0, O, I and l. A value containing one of them is not Base58 — it is probably Base62 or Base64, or it was transcribed by hand and a character was misread.
Fix:
Check for a zero that should be a capital O, or a lowercase l that should be a 1. If the value legitimately contains them, it is a different encoding.

A decoded Base32 secret gives the wrong TOTP codes.

Why:
Base32 secrets are often shared without padding and in lowercase, and some tools reject both. Others silently decode a truncated value.
Fix:
This accepts either case and works with or without padding. If codes still differ, the mismatch is the time step or the digit count, not the secret.

A Base58 value round-trips to something shorter.

Why:
Leading zero bytes were dropped. In base-58 arithmetic they carry no value, so they must be counted and re-emitted as leading ones — an implementation that forgets produces a shorter, different value.
Fix:
Nothing to do here — leading zeros are preserved, and the tool says so when the input has them.

Frequently asked questions

Why does Base58 leave out some characters?
It drops 0, O, I and l because those are the characters people confuse when reading a value aloud or retyping it, and + and / because they complicate double-click selection and URLs. The alphabet is designed for values humans handle.
Why do leading zeros matter so much?
Base58 encodes the input as one large number, and leading zero bytes carry no numeric value. They are re-emitted as leading "1" characters instead. Dropping them yields a different address, which is a real way funds have been lost.
Can I decode a TOTP secret with this?
Yes — TOTP secrets are Base32, and this accepts them in either case and with or without padding. The decoding happens in your browser, which for a shared secret is the only acceptable arrangement.

Related tools

Last updated