Online Base32/Base58 Encoder: Alphabets, Checksums, and Base64 Size Compare

What Is Base32 / Base58 Encoding

Base32 and Base58 turn binary into printable text, in the same family as Base64, but tuned for human transcription / dictation and crypto-style addresses. Try the Base32/Base58 encoder: pick RFC 4648 or Crockford, raw Base58 or Base58Check, then compare encoded length against Base64 for the same input.

How the three encodings split the work

Rule of thumb: machines → Base64; humans writing or speaking → Base32; address strings → Base58, and real money almost always wraps Base58Check.

Why Base32 helps humans

• Avoids confusing pairs such as 0/O and 1/I (RFC 4648 fills digit slots with 2–7).
• Uppercase-only forms survive case-folding channels (some mail and DNS paths).
• TOTP / HOTP authenticator secrets standardized on RFC 4648 Base32.

Why Base58 helps addresses

• Drops 0, O, I, and l to cut transcription mistakes.
• Avoids +, /, and =, which break URL paste and double-click selection.
• Raw Base58 has no checksum — Bitcoin addresses use Base58Check; the alphabet alone does not validate typos.

How to use the tool

With the Base32/Base58 encoder:

1. Paste plaintext (encode) or an encoded string (decode).
2. Choose Base32 or Base58.
3. Pick the alphabet variant:
   • Base32: RFC 4648 (TOTP) or Crockford (spoken-friendly; decode maps O→0, I/L→1).
   • Base58: raw Bitcoin Base58 or Base58Check (version byte + first 4 bytes of double SHA-256).
4. Encode or decode; invalid characters report a position, and Base58Check failures say so clearly.
5. After encode, a size panel lists Base32 / Base58 / Base64 lengths and overhead for the same UTF-8 input — full Base64 round-trips stay on the Base64 tool.

Encoding in code

JavaScript (RFC 4648 Base32 sketch)

// Illustrative only — prefer a tested library or the same logic as this site
function base32Encode(buffer) {
  const alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567';
  let bits = '';
  for (const byte of buffer) {
    bits += byte.toString(2).padStart(8, '0');
  }
  let result = '';
  for (let i = 0; i < bits.length; i += 5) {
    const chunk = bits.substr(i, 5).padEnd(5, '0');
    result += alphabet[parseInt(chunk, 2)];
  }
  return result;
}

Python

import base64

def base32_encode(data: bytes) -> str:
    return base64.b32encode(data).decode('ascii')

# Base58 / Base58Check need an extra library, e.g. pip install base58
import base58
def base58_encode(data: bytes) -> str:
    return base58.b58encode(data).decode('ascii')

Crockford's variant: built for reading codes aloud

Crockford Base32 drops I, L, O, and U (U also avoids accidental profanity). Decode treats O/o as 0 and I/i/L/l as 1, and often allows hyphens for chunking. ULIDs and other human-verified IDs use it. Choose Crockford when two people confirm a code on a call; keep RFC 4648 for authenticator secrets.

Base58Check: the checksum pattern (not raw Base58)

Raw Base58 is only an alphabet. Bitcoin-style addresses typically: prepend a version byte → payload → append the first four bytes of SHA-256(SHA-256(version‖payload)) → Base58 the whole thing. One mistyped character fails validation instead of sending funds into a void. This tool's Base58Check mode demos that wrap with version 0x00; decode verifies the checksum first and errors loudly on mismatch. If users hand-type encoded strings, copy the checksum pattern — not just the alphabet.

Size: how they compare to Base64

For the same UTF-8 text:

• Base64: about +33% (3 bytes → 4 characters).
• Base32: about +60% (5 bits per character, plus RFC padding).
• Base58: between them, data-dependent, with no = padding.

The tool's post-encode panel computes all three lengths on one input. Prefer Base64 (or raw binary) for bulk transport; Base32/Base58 buy readability and error resistance, not density.

Worked example: encoding Hello

Paste the same string into the Base32/Base58 encoder and read the compare panel — the overhead percentages update live so you can decide whether a human-friendly alphabet is worth the extra characters on the wire. For pure Base64 density math, see Why Base64 grows ~33%.

When checksums matter (and when they do not)

Raw Base32 / Base58 only change the alphabet. A single flipped character still decodes to some bytes — often silently wrong. Base58Check (and Crockford with an optional check symbol in some deployments) exist so transcription errors fail closed. Use checksummed forms for money, recovery phrases adjacent to wallets, and any ID a human will re-type; skip them for machine-to-machine blobs where TLS already protects integrity and you only need an alphabet.

Common pitfalls

• Decoding a Bitcoin address as raw Base58 and treating the result as UTF-8 prose — addresses are binary payloads.
• Mixing Crockford and RFC 4648 for TOTP — authenticators expect RFC; spoken codes expect Crockford.
• Forcing Base58 when the string contains 0/O/I/l — those are outside the Bitcoin alphabet; the tool hints that Base32 may fit better.
• Assuming “Base58 means checksummed” — only Base58Check (or similar wraps) validate.

FAQ

What is the difference between Base32 and Base64?

Base32 commonly uses uppercase letters and digits 2–7 (32 symbols); Base64 uses mixed case, digits, and +/ (64 symbols). Base32 is easier for humans and larger on the wire. Internals and Unicode notes: Base64 encoding guide.

Why does Bitcoin use Base58 instead of Base64?

To drop confusable characters and avoid + / in copy-paste. Addresses also wrap Base58Check; raw Base58 alone does not catch typos.

How do I choose an encoding?

• HTTP / API / email attachments → Base64
• TOTP secrets → Base32 (RFC 4648)
• Spoken / ULID-style codes → Base32 (Crockford)
• Crypto-style address strings to verify → Base58Check
• Alphabet-only, no checksum → raw Base58

Related reading

• Base64 encoding guide
• Base64 vs Base64URL: JWT and PEM
• Encoding troubleshooting handbook
• UUID generator (includes ULID)

Triage notes

The decision table at the top splits by who reads the output: machine channels get Base64, hand-copied or spoken strings get Base32, address-style strings get Base58 — the selection checklist and pitfall entries later in the article are all expansions of that table. The point that raw Base58 has no checksum (Bitcoin addresses use Base58Check) is repeated throughout because it is the single most common misconception, and the checksum boundary is drawn deliberately: money-adjacent IDs and anything a human re-types deserve the checksummed form, while machine-to-machine flows already covered by TLS can skip it. The size comparison states its conclusion plainly — what Base32/Base58 buy you is readability and error resistance, not density.

This guide is part of the ToolVault toolkit. More free local-first tools at the homepage.