About

Base62 encoding maps binary data onto a 62-character alphabet: 0-9, A - Z, a - z. It produces URL-safe, filename-safe output without special characters - unlike Base64, which emits +, /, and =. This tool reverses the encoding: it takes a Base62 string and recovers the original byte sequence. Incorrect decoding silently corrupts data. A single invalid character in the input invalidates the entire output because Base62 is a positional numeral system in base 62, and every digit affects every byte of the result.

The decoder uses arbitrary-precision arithmetic (BigInt) internally, so it handles inputs of any practical length without overflow. Output can be rendered as UTF-8 text, ASCII, or hexadecimal bytes. Note: if the original data was not valid UTF-8, the text output may contain replacement characters (U+FFFD). Use hex mode to inspect raw bytes in that case.

Formulas

Base62 treats the input string as a number in base 62. Each character maps to a digit value d in the range [0, 61]. The decoded integer N is computed by Horner's method:

N = n−1∑i=0 d_i ⋅ 62ⁿ⁻¹⁻ⁱ

Iteratively this becomes the loop: N = N × 62 + d_i for each character left to right. The resulting integer N is then converted to a big-endian byte array by repeated division by 256:

byte_k = N mod 256 , N = N256

The alphabet mapping is: digits 0-9 → values 0-9, uppercase A - Z → 10-35, lowercase a - z → 36-61. Information density is log₂(62) ≈ 5.954 bits/char, compared to 6.0 bits/char for Base64.

Where N = decoded integer, d_i = digit value of the i-th character, n = length of the encoded string, and byte_k = the k-th output byte (collected in reverse order).

Reference Data

Encoding	Alphabet Size	Characters Used	URL Safe	Padding	Efficiency (bits/char)	Common Use
Base62	62	0-9 A - Z a - z	Yes	None	5.95	Short URLs, ID generation
Base64	64	A - Z a - z 0-9 + /	No	=	6.00	Email (MIME), data URIs
Base64url	64	A - Z a - z 0-9 - _	Yes	Optional	6.00	JWT, URL parameters
Base58	58	1-9 A - H J - N P - Z a - k m - z	Yes	None	5.86	Bitcoin addresses
Base36	36	0-9 a - z	Yes	None	5.17	Case-insensitive IDs
Base32	32	A - Z 2-7	Yes	=	5.00	TOTP secrets, Crockford IDs
Base16 (Hex)	16	0-9 A - F	Yes	None	4.00	Color codes, checksums
Base85 (Ascii85)	85	! - u	No	~>	6.41	PDF, PostScript
Base91	91	Printable ASCII subset	No	None	6.51	Compact binary-to-text
Base128	128	Full 7-bit ASCII	No	None	7.00	Protobuf varints
Base256	256	All byte values	No	None	8.00	Raw binary storage
Hexadecimal	16	0-9 a - f	Yes	None	4.00	MAC addresses, hashes
Octal	8	0-7	Yes	None	3.00	Unix permissions
Binary	2	0 1	Yes	None	1.00	Bitwise debugging

Frequently Asked Questions

Exactly 62 characters: digits 0 - 9 (values 0-9), uppercase letters A - Z (values 10-35), and lowercase letters a - z (values 36-61). Any character outside this set - including +, /, =, spaces, or Unicode - will cause a decoding error. The decoder validates input before processing and reports the position of the first invalid character.

Base64 uses +, /, and the padding character =, all of which have reserved meanings in URLs, filenames, and XML. Base62 restricts itself to purely alphanumeric characters. This means a Base62 string can be embedded directly in a URL path segment, used as a filename, or placed in a JSON value without any escaping. The trade-off is slightly lower information density: 5.954 bits/char vs. 6.0 bits/char.

JavaScript's Number type is a 64-bit IEEE 754 float, which can only represent integers exactly up to 2⁵³ − 1 (about 9 × 10¹⁵). A Base62 string of just 10 characters can represent values up to 62¹⁰ ≈ 8.4 × 10¹⁷, which already exceeds safe integer range. BigInt provides arbitrary-precision integer arithmetic, so the decoder handles strings of any length without silent precision loss.

The decoder recovers the exact byte sequence. When rendered as UTF-8 text, invalid byte sequences are replaced with the Unicode replacement character U+FFFD (‘�’). To inspect the raw bytes without interpretation, switch the output mode to Hex. This shows each byte as a two-character hexadecimal value (e.g., 00 for a null byte, FF for byte 255).

No. Unlike Base64 (RFC 4648) or Base32 (RFC 4648), Base62 has no formal standard. The most common convention uses the alphabet 0-9A - Za - z with digit values in that order, which this tool follows. Some implementations swap the positions of uppercase and lowercase blocks. If your encoded data uses a different alphabet order, the decode will produce incorrect output. Always verify the alphabet convention with the encoder.

Yes. In Base62 as a positional system, a leading 0 character has digit value 0. Mathematically, leading zeros do not change the integer N. However, some Base62 implementations use leading 0 characters to represent leading null bytes (0x00) in the original data, similar to Base58's convention. This decoder treats the input as a pure number, so leading zeros are absorbed. If your encoder preserves leading null bytes via leading zeros, the output may be shorter than expected.