About

Base64 encodes binary data into 64 printable ASCII characters (A - Z, a - z, 0 - 9, +, /) plus the padding character =. Base62 uses the same alphanumeric set but drops the two non-alphanumeric symbols, producing output that is URL-safe, filename-safe, and safe for use inside double-quoted JSON strings without escaping. The trade-off is a roughly 1 - 2% longer output because log₂(62) ≈ 5.954 bits per character versus log₂(64) = 6 bits per character. Getting the conversion wrong silently corrupts payloads. A single misplaced character in either alphabet produces garbage bytes on decode.

This tool performs lossless, bi-directional conversion by treating the raw byte payload as an arbitrary-precision integer and re-encoding it in the target radix. A one-byte length prefix is stored so the original byte count survives the round-trip. The implementation uses native BigInt arithmetic. Note: this tool approximates constant-time performance for inputs under 100 kB. Beyond that, BigInt division chains grow quadratically.

Formulas

The conversion treats the input's decoded byte array as a base-256 big integer N, then re-encodes it digit-by-digit in the target base.

N = n−1∑i=0 b_i ⋅ 256ⁿ⁻¹⁻ⁱ

where b_i is the i-th byte. The target encoding repeatedly extracts remainders:

d_k = N mod R, then N = N − d_kR

where R = 62 (or 64) is the target radix and each d_k maps to a character in the target alphabet. Digits are collected least-significant first, then reversed. A single length-prefix byte stores the original payload size modulo 256 to resolve leading-zero ambiguity during round-trip conversion.

Reference Data

Property	Base64 (RFC 4648)	Base62
Alphabet size	64	62
Characters	A-Z a-z 0-9 + /	0-9 A-Z a-z
Padding	= (up to 2)	None
Bits per character	6.000	5.954
Expansion ratio (vs binary)	4/3 ≈ 1.333	≈ 1.344
URL-safe	No (+ and / need encoding)	Yes
Filename-safe	No	Yes
JSON-safe (no escaping)	No (/ may be escaped)	Yes
Used in	MIME, PEM, JWT, Data URIs	Short URLs, ID hashing, Redis keys
Case-sensitive	Yes	Yes
Common implementations	btoa/atob, OpenSSL	Custom libraries, Hashids
Padding overhead (worst case)	2 bytes	0 bytes
Encoding standard	RFC 4648 §4	No formal RFC
Base64url variant	A-Z a-z 0-9 - _	N/A
Typical use: 16-byte UUID	24 chars	22 chars
Typical use: 32-byte hash	44 chars	43 chars
Decoding complexity	O(n)	O(n²) via BigInt
Sortable output	No (alphabet order differs)	Yes (lexicographic = numeric)

Frequently Asked Questions

Each Base64 character encodes exactly 6 bits (log₂64 = 6), while each Base62 character encodes log₂62 ≈ 5.954 bits. For a payload of n bytes (8n bits), Base62 requires ⌈8n ÷ 5.954⌉ characters versus ⌈8n ÷ 6⌉ for Base64. The difference is roughly 0.8% more characters.

Yes. The tool prepends a length-prefix byte before computing the big integer, which preserves leading zero bytes. Without this prefix, a payload starting with 0x00 would lose that byte during BigInt conversion because N would be the same with or without leading zeros. The prefix guarantees a unique round-trip.

No. Base64url replaces + with - and / with _. You must first replace those characters back to standard Base64 before pasting into this tool. The tool validates strictly against the canonical Base64 alphabet and will flag invalid characters.

The tool uses native BigInt, which has no fixed upper limit. However, the repeated division algorithm runs in O(n²) time relative to digit count. Inputs under 100 kB convert in under a second on modern hardware. Inputs above 500 kB may take several seconds. The UI displays a progress indicator for long operations.

This tool uses the standard Base62 alphabet 0-9 A-Z a-z (digits first). This means lexicographic string comparison of two Base62-encoded values of equal length matches their numeric order. If your system uses a different alphabet order (e.g., a-z A-Z 0-9), the encoded output will differ and sort differently.

Padding characters (=) are not part of the data payload. They are stripped before decoding to bytes. When converting back from Base62 to Base64, padding is re-added as required by the RFC 4648 standard (the output byte count determines whether 0, 1, or 2 padding characters are appended).