CruxDevCruxDev Tools Prompts
dev Utility • Zero-Server Privacy • 100% Client-Side

Base58 Encode / Decode

Bitcoin-style Base58 and Base58Check encoding/decoding for addresses, transaction IDs, and binary-to-text conversions.

Overview

Encodes and decodes Bitcoin-style Base58, the 58-character alphabet that removes 0, O, I and l to keep human-transcribed strings unambiguous. Encoding converts your UTF-8 text to bytes, treats them as one big number, and divides repeatedly by 58; leading zero bytes become leading 1 characters. Everything runs client-side with JavaScript BigInt arithmetic.

How It Works

Choose Encode or Decode with the toggle. On encode, paste text and the Base58 string appears live; each leading zero byte in the input adds one leading 1 to the output. On decode, paste a Base58 string and the tool multiplies the digit values back into a big integer, converts it to bytes, and renders them as UTF-8. Characters outside the alphabet, including the excluded 0, O, I and l, produce an explicit Invalid result instead of guessing.

Step-by-Step Usage Guide

  1. Select Encode, paste your text, and copy the Base58 output, or select Decode to reverse it.
  2. Paste Base58 data, avoiding the excluded characters 0, O, I and l.
  3. Watch for leading 1 characters in encoded output; each one marks a zero byte in the source.
  4. Click the output panel to copy the result.

Technical Specifications & Standards

Base58 is not a bit-slicing scheme like Base32 or Base64; it is base conversion, which is why the implementation builds a BigInt from the input bytes and repeatedly takes n modulo 58. That has two visible consequences. First, there is no padding concept: the length of the output depends on the numeric value of the data, so equal-length inputs can produce different-length encodings. Second, zero bytes are invisible to the number, so the encoder re-inserts one leading 1 per leading zero byte to make the encoding reversible, the same convention Bitcoin uses. What this tool deliberately does not implement is Base58Check: real Bitcoin addresses append a 4-byte double-SHA-256 checksum and a version byte to the payload before encoding. You can still decode an address here, but the bytes you get back include the version and checksum, and nothing verifies them, so a single mistyped character inside the payload region decodes to different bytes without any warning. For verification work use a Base58Check-aware tool; use this one for plain alphabet conversion, payloads you already trust, or learning the numeric structure.

Targeted Use Cases

  • Decoding testnet or mainnet identifiers when debugging blockchain tooling.
  • Converting short binary identifiers into strings that survive handwriting and phone calls.
  • Understanding why Bitcoin chose this alphabet over Base64 for user-facing values.
  • Checking whether a suspicious string is even valid Base58 before feeding it to stricter software.

Notes & Gotchas

  • Do not treat output from this tool as a validated Bitcoin address; no checksum is verified.
  • Strip whitespace from pasted strings, since a space is not in the alphabet and fails the decode.
  • Expect output length to vary with numeric value; that is correct base conversion behavior, not a bug.
  • When transcribing Base58 by hand, double-check the positions of l, I, and 1; the look-alike-free alphabet will not save you from a shifted string.

Frequently Asked Questions

Which characters are missing from Base58 and why?

0 (zero), O (capital o), I (capital i) and l (lowercase L) are removed because they look alike in many fonts. The alphabet has 58 symbols: 26 lowercase, 25 uppercase, and the digits 1-9.

Can this tool validate a Bitcoin address?

No. It implements plain Base58, not Base58Check, so the version byte and 4-byte checksum inside an address are decoded as ordinary payload bytes and never verified. A typo in the middle of an address will decode without complaint.

Why do leading zeros become the digit 1?

Zero bytes contribute nothing to the big-number value, so the encoder prepends one 1 per leading zero byte to keep the encoding reversible. This mirrors the Bitcoin convention exactly.

Why is my output longer or shorter than expected?

Base58 is a numeric base conversion, not a fixed-bit packing like Base64, so output length depends on the magnitude of the data. Only leading zero bytes have a predictable effect: each adds exactly one character.