dev101.io

Base62 Encode / Decode

Encode and decode Base62 strings — shorter than Base64, URL-safe, UTF-8 clean.

Loading tool…

How to use Base62 Encode / Decode

  1. Choose Encode or Decode at the top of the tool.
  2. Paste your raw text (Encode mode) or Base62 string (Decode mode) into the left pane.
  3. Watch the output update on every keystroke. Any invalid Base62 character in Decode mode surfaces with its exact position.
  4. Press ⌘/Ctrl + Enter to swap modes and feed the last output back as input — handy for a quick round-trip sanity check.
  5. Use Copy output to grab the result, or Share to produce a URL that restores your session.

Base62 Encode / Decode

A lossless Base62 converter for text and arbitrary byte sequences. Paste, pick a mode, copy — no sign-up, no uploads, no server round-trip. Every transform runs in your browser using TextEncoder / TextDecoder and native BigInt arithmetic, so the tool keeps working offline once the page is cached.

Why Base62

Base62 is what you reach for when you want a compact, printable encoding that survives any text-based channel without escaping: URL paths, query parameters, filenames, shell arguments, email subjects. Its alphabet is the 62 characters every developer already agrees are "safe" — 0-9, A-Z, a-z — so there's never a question about whether a downstream system will corrupt +, /, or = the way it sometimes does with Base64.

The most common place you'll see Base62 in the wild is short-URL services. A service that needs to expose sequential IDs compactly encodes the integer into Base62, turning 1_500_000_000 into a seven-character handle that's still purely alphanumeric. This tool isn't specifically a short-URL generator, but it uses the same alphabet and the same encoding strategy, so it can decode IDs produced by any Base62 scheme that interprets bytes as a big-endian integer.

How the encoding works

The naive "treat each byte as a Base62 digit" approach doesn't work, because 256 doesn't divide evenly into powers of 62. Instead, the encoder interprets the entire byte sequence as a single big-endian unsigned integer, then repeatedly divides by 62 to emit digits. This is the same pattern base-x libraries use for Base58 (Bitcoin) and similar alphabets.

Two details make the round-trip lossless:

  • Leading zero bytes become leading 0 characters. Without this, encoding [0x00, 0xff] and [0xff] would produce identical output. The encoder counts leading zero bytes and prefixes one 0 character per zero byte; the decoder does the reverse.
  • UTF-8 normalisation. Text input is piped through TextEncoder before the Base62 step, so every Unicode code point — emoji, CJK ideographs, accented Latin — round-trips cleanly.

Encode to Base62

Paste any text into the left pane in Encode mode. The output is a pure alphanumeric string using only 0-9A-Za-z. Output length is predictable: for an N-byte input the Base62 encoding is approximately N × log₂(256) / log₂(62) ≈ N × 1.344 characters, which is a little shorter than Base64's N × 4/3 ≈ 1.333. The small difference comes from Base62 not needing padding.

Decode from Base62

Decode mode accepts any Base62 string and attempts to reconstruct the original byte sequence, then decode it as UTF-8 text. If the bytes aren't valid UTF-8 (for example, a Base62-encoded SHA-256 digest), the tool surfaces a typed error rather than returning replacement glyphs silently.

Three specific error conditions produce clear, actionable messages:

  • Invalid characters. Anything outside the Base62 alphabet — a stray +, a slash, whitespace in the middle of the string — produces an error with the exact offending character and its position.
  • Empty or whitespace-only input. Decode won't guess at an empty string.
  • Non-UTF-8 payload. When the decoded bytes aren't valid UTF-8, the error says so explicitly — the tool never quietly replaces bad bytes with U+FFFD replacement characters.

What this tool deliberately doesn't do

  • Custom alphabets. There are many Base62 alphabets in the wild — ordered differently for lexicographic sort, case-insensitive, etc. This tool uses the standard 0-9A-Za-z ordering; variants live in their own tools to keep the surface area small and the output predictable.
  • Binary file encoding. This is a string tool. If you need to encode a whole file, pipe it through the CLI and paste the result — browser-side memory constraints make multi-megabyte single-shot encodes a bad fit for the UI.
  • Base58 / Base32 / Base64. Each alphabet gets its own tool. See the Related section below.

Privacy promise

Every byte of your input stays in your browser. No analytics on input, no server logging, no third-party scripts in the transform path. The Share button encodes state into the URL fragment — which browsers never send to servers — so shared links preserve the same guarantee.

Related tools

Frequently asked questions

How is Base62 different from Base64?

Base62 uses the 62 alphanumeric characters 0-9, A-Z, a-z and nothing else. Base64 adds `+` and `/` to reach 64 characters, plus `=` for padding. Because those three extra symbols are reserved in URLs, filenames, and shell contexts, Base62 is the natural choice anywhere the output needs to survive round-tripping through a URL path, a query string, or a filesystem. Base62 is roughly 5% longer than Base64 for the same payload, which is a negligible cost for the guarantee that you'll never need to percent-encode the result.

Is Base62 the same alphabet as short-URL services like Bitly or YouTube?

Short-URL services typically use a Base62 alphabet, yes, but the encoding strategy differs. They usually encode an auto-incrementing integer ID into Base62 digits — so `1` becomes `1`, `62` becomes `10`, and so on. This tool instead encodes arbitrary byte sequences by treating the bytes as a big-endian integer, which preserves round-trip fidelity for any input including emoji and binary data. Both approaches share the same 62-character alphabet, so values produced by one can be read by the other when the input is a plain number.

Why does my output have leading `0` characters, and what do they mean?

Base62 preserves leading zero bytes in your input by emitting one `0` character per leading zero byte at the start of the output. Without this, encoding bytes `[0x00, 0xff]` and bytes `[0xff]` would produce the same output, breaking the round-trip. The `0` prefix is explicit, unambiguous, and lets the decoder reconstruct the original byte string exactly. If your input is plain text that doesn't start with a null byte, you won't see leading zeros in the output.

Is this tool sending my input to a server?

No. Encoding and decoding both run entirely in your browser via `TextEncoder`, `TextDecoder`, and JavaScript's native BigInt arithmetic. There is no encode or decode API endpoint, no analytics on input content, and no third-party script in the transform path. The Share button encodes state into the URL fragment (`#…`), which browsers never transmit to servers by design.

Related tools