About

Base62 encoding maps binary data onto the 62-character alphabet 0-9, A - Z, a - z. It avoids URL-unsafe characters (+, /, =) present in standard Base64 (RFC 4648), making it common in short URL services, database keys, and token generation. Base64 uses 64 symbols and is the dominant encoding for embedding binary payloads in JSON, email (MIME), and data URIs. Converting between them requires decoding the source into its raw byte representation, then re-encoding into the target alphabet. A single misidentified character will corrupt the entire output because both schemes treat input as a positional numeral in their respective radix.

This tool performs exact, lossless conversion using arbitrary-precision integer arithmetic (BigInt). It does not approximate or truncate. Note: Base62 has no canonical padding scheme, so leading zero-bytes in the original data may not round-trip identically unless a length prefix is used. If your Base62 variant uses a non-standard alphabet order, verify the mapping before relying on the output in production systems.

Formulas

Both Base62 and Base64 are positional numeral systems. A string S of length n in base b represents an integer N:

N = n−1∑i=0 S_i ⋅ bⁿ⁻¹⁻ⁱ

Where S_i is the numeric value of the i-th character in the alphabet. The conversion pipeline is:

Base62(S) → N ∈ Z → byte[] → Base64(byte[])

To extract bytes from N, repeatedly divide by 256 and collect remainders (big-endian):

byte_k = N mod 256, N ← N256

The bits-per-character efficiency is log₂(b). For Base62: log₂(62) ≈ 5.954 bits/char. For Base64: exactly 6 bits/char.

Where: N = decoded integer value, b = radix (62 or 64), S_i = ordinal of character at position i, n = string length.

Reference Data

Property	Base62	Base64 (RFC 4648)
Alphabet Size	62	64
Characters Used	0-9 A - Z a - z	A - Z a - z 0-9 + /
Padding Character	None	=
URL Safe	Yes	No (requires URL-encoding or Base64url variant)
Space Efficiency (bits/char)	5.954 (log₂62)	6.000 (log₂64)
Expansion Ratio (vs raw bytes)	≈ 1.344×	≈ 1.333×
Common Uses	Short URLs, UUIDs, tokens	MIME email, data URIs, JWTs
Case Sensitive	Yes	Yes
Sorting Preserves Order	Yes (lexicographic = numeric)	No (alphabet order differs)
Regex Validation	/^[0-9A-Za-z]+$/	/^[A-Za-z0-9+/]+={0,2}$/
Null Byte Handling	Leading zeros lost without prefix	Preserved (3-byte grouping)
RFC / Standard	No formal RFC	RFC 4648
Base64url Variant	N/A	Replaces + → -, / → _
Encoding 128-bit UUID	22 chars	24 chars (with padding)
Encoding 256-bit hash	43 chars	44 chars (with padding)
JavaScript Native Support	Manual implementation required	btoa() / atob()

Frequently Asked Questions

Base62 has no formal RFC, so alphabet ordering varies between implementations. Some use 0-9a - zA - Z (lowercase first), others use 0-9A - Za - z (uppercase first). This tool uses the latter convention (0-9A - Za - z), which is the most common in libraries like Java's and most short-URL services. If your source data was encoded with a different alphabet order, every character above 9 will map to a different numeric value, producing entirely different bytes.

Not inherently. Base62 encodes data as a single large integer. Leading zero bytes in the original binary (e.g., 0x00 0x00 0x4F) are lost because they don't affect the integer value. Base64 preserves them because it operates on fixed 3-byte groups. If your protocol requires preserving leading null bytes, you must store the original byte length separately or use a length-prefixed encoding.

No. Base64 encodes 6 bits/char while Base62 encodes log₂(62) ≈ 5.954 bits/char. For the same binary payload, Base62 strings are slightly longer. The advantage of Base62 is character-set safety: it uses only alphanumeric characters, avoiding issues with URL encoding, shell escaping, and filename restrictions.

Standard Base64 pads output with = to make the length a multiple of 4. This tool accepts Base64 input both with and without padding. When producing Base64 output, it always includes correct padding per RFC 4648. The padding characters carry no data; they only signal the decoder how many trailing bytes to discard from the last 3-byte group.

The practical limit is determined by your browser's BigInt performance and memory. Strings up to approximately 10,000 characters convert in under 100 ms on modern hardware. Beyond 50,000 characters, the BigInt multiplication becomes noticeably slow. For very large payloads, streaming chunk-based conversion (splitting into fixed-size blocks) is preferable, but that requires both encoder and decoder to agree on the block size.

Both Base62 and Base64 operate on raw bytes, not characters. If the original data was UTF-8 text, the bytes that emerge after decoding Base62 are the same UTF-8 bytes, which you can then re-encode to Base64. The character encoding is embedded in the byte stream itself. This tool treats all data as an opaque byte sequence and does not alter encoding. If you paste a Base62-encoded UTF-8 string, the resulting Base64 will decode to the same UTF-8 text.