About

Incorrect base conversion is a silent source of data corruption in cryptographic hashing, memory addressing, and network protocol design. A single misinterpreted hexadecimal nibble in a MAC address or a mis-mapped base-64 index in a JWT token invalidates the entire payload. This tool converts any integer or fractional number between radices 2 through 64 using arbitrary-precision arithmetic via BigInt, eliminating the IEEE-754 floating-point truncation that plagues naive implementations. The digit alphabet follows the convention 0 - 9, A - Z, a - z, +, / - consistent with Base64 (RFC 4648) for bases above 62.

Fractional parts are approximated via repeated multiplication to a configurable precision of up to 32 digits. Note: most fractional values cannot be represented exactly in a different base (e.g., 0.1 in base 10 is repeating in base 2). The tool truncates, not rounds, fractional output. Negative numbers are handled by preserving the sign prefix. For bases above 36, digits become case-sensitive.

Formulas

The integer part of a number N expressed in base b with digits d_k is evaluated as:

N = n∑k=0 d_k ⋅ b^k

Conversion from base b₁ to base b₂ proceeds in two stages. First, Horner’s method accumulates the source digits into a decimal (base-10) BigInt:

N₁₀ = d_n ⋅ b₁ⁿ + d_n−1 ⋅ b₁ⁿ⁻¹ + … + d₀

Second, repeated division by b₂ extracts target digits from least-significant to most-significant:

d_k = N₁₀ mod b₂ , N₁₀ ← N₁₀b₂

For fractional parts, repeated multiplication extracts digits from most-significant to least-significant: multiply the fractional remainder by b₂, take the integer part as the next digit, and repeat up to the configured precision p.

Where: N = numeric value, b = base (radix), d_k = digit at position k, n = number of digits minus one, p = fractional precision (max 32).

Reference Data

Base	Name	Digits Used	Common Use
2	Binary	0 - 1	CPU logic, bitfields, networking masks
3	Ternary	0 - 2	Balanced ternary computing, Soviet Setun computer
5	Quinary	0 - 4	Tally counting systems, some historical numeral systems
8	Octal	0 - 7	Unix file permissions (chmod), PDP-11 architecture
10	Decimal	0 - 9	Human-readable numbers, financial calculations
12	Duodecimal	0 - B	Timekeeping (12 hours), imperial measurements (12 inches)
16	Hexadecimal	0 - F	Memory addresses, CSS colors, MAC addresses, SHA hashes
20	Vigesimal	0 - J	Maya numeral system, French counting (quatre-vingts)
32	Duotrigesimal	0 - V	Crockford Base32 encoding, z-base-32, Geohash
36	Hexatrigesimal	0 - Z	Case-insensitive compact encoding, Reddit post IDs
58	Base58	Alphanumeric minus 0OIl	Bitcoin addresses, IPFS hashes (ambiguity-free)
60	Sexagesimal	0 - x	Babylonian math, time (60 seconds), angle degrees
62	Base62	0 - z	URL shorteners (bit.ly), YouTube video IDs
64	Base64	0 - z, +, /	MIME encoding, data URIs, JWT tokens (RFC 4648)

Frequently Asked Questions

Most fractions cannot be represented exactly in a different base. For example, 0.1 in base 10 becomes 0.0001100110011... (repeating) in base 2. The tool truncates fractional output at the configured precision (default 16 digits, maximum 32) rather than rounding. This prevents false precision. If you need exact rational arithmetic, represent the number as a fraction (numerator/denominator) and convert each part separately.

For bases 2-10, digits are 0-9. For bases 11-36, uppercase letters A - Z extend the alphabet (case-insensitive input). For bases 37-62, lowercase letters a - z are appended after Z, making input case-sensitive. Bases 63-64 add "+" and "/" respectively, following RFC 4648 Base64 convention. When entering digits for base 16, both "a" and "A" are accepted. For base 62, "a" (value 36) and "A" (value 10) are distinct.

Yes. The integer conversion path uses JavaScript BigInt, which supports arbitrary-precision integers with no upper bound (limited only by available memory). This eliminates the 2^53 precision limit of IEEE-754 floating-point. You can convert 256-bit cryptographic hashes or 1024-bit RSA moduli between hex and decimal without any truncation.

Base58 (used by Bitcoin) deliberately excludes visually ambiguous characters: 0 (zero), O (uppercase o), I (uppercase i), and l (lowercase L). This prevents transcription errors when humans copy addresses. Base62 includes all 62 alphanumeric characters for maximum density. For machine-only contexts (API tokens, database IDs), Base62 is more compact. For human-readable contexts, Base58 is safer. This tool uses the standard sequential alphabet for all bases; it does not implement the Bitcoin-specific Base58 alphabet permutation.

Prefix the input with a minus sign (−). The tool strips the sign, converts the absolute value, and prepends the minus sign to the result. Two's complement or sign-magnitude encoding is not applied; the output is a signed positional numeral. If you need two's complement for a specific bit width, convert the absolute value to binary and apply the complement manually.

Yes. The tool automatically detects and strips common prefixes: "0x" and "0X" for base 16, "0b" and "0B" for base 2, and "0o" and "0O" for base 8. If a prefix is detected but the selected source base does not match, the tool shows a warning and ignores the prefix. You can also enter numbers without any prefix.

Standard Base64 encoding (RFC 4648) operates on byte streams - it encodes binary data into ASCII text. This tool performs positional numeral conversion: it treats the input as a mathematical number and re-expresses it in base 64 using a sequential digit alphabet. The results differ because Base64 encoding is not a number system conversion; it is a byte-to-character mapping with padding. Use this tool for mathematical radix conversion, not for encoding binary files.