Base32, Base58, Base62 and Base85 encoder and decoder
Encode text or bytes as Base16, Base32, Crockford, Base58 or Base58Check, Base62, Ascii85 or Z85, and decode them back with exact error positions.
A clear answer. Here’s how.
Base16, Base32 and Base32hex follow RFC 4648 sections 8, 6 and 7: bytes are taken as a bit stream, 4 or 5 bits per character, and Base32 is padded with = to a multiple of 8 characters. Crockford Base32 uses the same bit grouping with Crockford’s alphabet (no I, L, O or U); when decoding, O reads as 0, I and L as 1, and hyphens are ignored; the optional check symbol is not supported. Base58 (the Bitcoin alphabet, without 0, O, I and l) and Base62 (0–9, A–Z, a–z) read the bytes as one big-endian number and write it in that base, with one leading 1 (or 0) for each leading zero byte; Base58Check appends the first four bytes of SHA-256(SHA-256(data)) before encoding and checks them when decoding. Ascii85 is Adobe’s: 4 bytes become 5 characters from ! to u, z stands for four zero bytes and a short final group is padded and trimmed. Z85 (ZeroMQ RFC 32) needs a multiple of 4 bytes. Decoding errors give the line and column of the first character that does not belong. Base62 has no standard: other libraries may order the alphabet differently or drop leading zeros. The Bitcoin-specific meaning of version bytes is not interpreted.
How this is checked
5 reference checks passed These 5 cases were run when this page was built, on 20 October 2026, and all reproduce within the stated tolerance. The same cases are part of the automated tests that run on every change to Toolmoz. Engine version 1.
See the checks and where each expected answer comes from
Case 1
- Inputs
- Direction encodeEncoding base32Input foobarBase32 padding when encoding yes
- Expected, and what Toolmoz gave
- text expected MZXW6YTBOI======, Toolmoz MZXW6YTBOI======Output characters expected 16, Toolmoz 16
- Where the expected answer comes from
- RFC 4648 section 10 test vector: BASE32("foobar") = "MZXW6YTBOI======"
- Allowed difference
- exact
Case 2
- Inputs
- Direction encodeEncoding base32hexInput foobarBase32 padding when encoding yes
- Expected, and what Toolmoz gave
- text expected CPNMUOJ1E8======, Toolmoz CPNMUOJ1E8======
- Where the expected answer comes from
- RFC 4648 section 10 test vector: BASE32-HEX("foobar") = "CPNMUOJ1E8======"
- Allowed difference
- exact
Case 3
- Inputs
- Direction encodeEncoding base58checkBytes to encode are given as hexInput 00f54a5851e9372b87810a8e60cdd2e7cfd80b6e31
- Expected, and what Toolmoz gave
- text expected 1PMycacnJaSqwwJqjawXBErnLsZ7RkXUAs, Toolmoz 1PMycacnJaSqwwJqjawXBErnLsZ7RkXUAsChecksum (first 4 bytes of SHA-256 of SHA-256) expected c7f18fe8, Toolmoz c7f18fe8
- Where the expected answer comes from
- Bitcoin wiki, Technical background of version 1 Bitcoin addresses, steps 4 to 9: version 00 plus hash f54a…6e31, checksum c7f18fe8, address 1PMycacnJaSqwwJqjawXBErnLsZ7RkXUAs
- Allowed difference
- exact
Case 4
- Inputs
- Direction encodeEncoding z85Bytes to encode are given as hexInput 86 4F D2 6F B5 59 F7 5B
- Expected, and what Toolmoz gave
- text expected HelloWorld, Toolmoz HelloWorld
- Where the expected answer comes from
- ZeroMQ RFC 32 test case: the 8 bytes 0x86 0x4F 0xD2 0x6F 0xB5 0x59 0xF7 0x5B encode as HelloWorld
- Allowed difference
- exact
Case 5
- Inputs
- Direction encodeEncoding ascii85Input Man Ascii85 delimiters when encoding no
- Expected, and what Toolmoz gave
- text expected 9jqo^, Toolmoz 9jqo^
- Where the expected answer comes from
- Wikipedia Ascii85 example: Man is 0x4D616E20 = 1298230816 = 24×85^4 + 73×85^3 + 80×85^2 + 78×85 + 61, and 24+33, 73+33, 80+33, 78+33, 61+33 are the characters 9 j q o ^
- Allowed difference
- exact
What this shows: the engine reproduces independently worked values for these cases. It does not prove every possible input is right. To test an answer you were given, see how to check a number; to see what is and is not checked across Toolmoz, see the accuracy ledger.
See a worked example
Worked example
A fixed demonstration, separate from the values you enter above.
- Direction
- Encode bytes as text
- Encoding
- Base32 (RFC 4648)
- Bytes to encode are given as
- Text (its UTF-8 bytes)
- Input
- foobar
- Base32 padding when encoding
- Pad with = to a multiple of 8 characters (RFC 4648)
- Ascii85 delimiters when encoding
- None
Example result
- Encoded
- MZXW6YTBOI======
- Input bytes
- 6
- Output characters
- 16
- Characters per byte
- 2.667
RFC 4648 section 6 alphabet A–Z and 2–7, 5 bits per character. Decoding ignores spaces, accepts lower case and checks the = padding.