Number base converter
Convert a number between any two bases from 2 to 36, including negative numbers and fractions, and see how the answer was reached: the repeated divisions, the positional weights, and the digit-by-digit remainders that reveal a repeating expansion. This page also covers binary to decimal and decimal to binary. Your input never leaves your browser.
How to use
- Type the number in Number. Digits are 0-9 and then a-z (a = 10 ... z = 35); case does not matter. Use
.for the radix point and a leading-for a negative number. Spaces and underscores are ignored as digit separators, and a0x,0bor0oprefix is accepted when it matches the "From" base. - Choose the From base the number is written in and the To base you want. For binary to decimal choose 2 and 10; for decimal to binary choose 10 and 2. The Swap button exchanges the two bases and moves the result into the input, so you can check a conversion by converting it back.
- Read the result at the top, then the working. The repeated division table converts the whole part: divide by the target base, write down the remainder, and read the remainders from the last to the first. The repeated multiplication table converts the fraction: multiply the fractional part by the target base and take the whole-number part as the next digit. The positional weights table shows what each input digit contributes.
- A repeating expansion is written with the repeating block in parentheses:
0.0(0011)means 0.0 followed by 0011 forever. The tool finds the block by watching for a remainder it has seen before, so the block is proved, not guessed. If it has not closed after Max fraction digits digits (default 64, at most 1024), the result ends in...and is cut, never rounded. - When both bases are powers of two (2, 4, 8, 16, 32) a regrouping view appears: each digit becomes a fixed group of bits, and the bits are regrouped outward from the radix point. This is why hex to binary can be done digit by digit, with no arithmetic.
- Copy share link puts the number and both bases after the
#in the address, so the same conversion opens for someone else. Nothing is sent anywhere; the fragment stays in the browser.
Worked examples
Every input and result below is recomputed by an automated test that runs the same engine as the tool above, and the paper derivations are checked separately, so this page cannot show a value the tool would not print.
Whole numbers: 255 to binary
Divide by 2 and keep the remainders: 255 = 127 x 2 + 1, 127 = 63 x 2 + 1, and so on, eight times, until the quotient is 0. Eight remainders of 1, read from the last to the first, give eight ones. Check: 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255.
From 10, to 2
Input: 255
Output: 11111111
A fraction that ends: 12.375 to binary
The whole part 12 is 8 + 4 = 1100. The fraction 0.375 doubles to 0.75 (digit 0), 1.5 (digit 1, keep 0.5) and 1.0 (digit 1, remainder 0), so the fraction is .011: 0.25 + 0.125 = 0.375.
From 10, to 2
Input: 12.375
Output: 1100.011
A fraction that never ends: 0.1 to binary
Double 0.1 and keep the whole-number digit: 0.1 → 0.2 (digit 0) → 0.4 (0) → 0.8 (0) → 1.6 (digit 1, keep 0.6) → 1.2 (1, keep 0.2) → 0.4 (0). The value 0.2 has already appeared, so the digits from there on repeat forever: the digit 0 first, then the block 0011.
From 10, to 2
Input: 0.1
Output: 0.0(0011)
This is why 0.1 cannot be stored exactly in binary floating point. The IEEE 754 page shows the nearest stored value.
The same method on 0.7 reaches a repeat after one leading digit:
From 10, to 2
Input: 0.7
Output: 0.1(0110)
Binary to decimal with positional weights
In 1010.101 the digits left of the point have weights 8, 4, 2, 1 and the digits right of it have weights 1/2, 1/4, 1/8. So 1 x 8 + 0 x 4 + 1 x 2 + 0 x 1 + 1/2 + 0/4 + 1/8 = 8 + 2 + 0.5 + 0.125 = 10.625.
From 2, to 10
Input: 1010.101
Output: 10.625
Between bases that are powers of two
Hexadecimal ff is the bits 1111 1111. Regrouped in threes from the right they are 011 111 111, which is octal 377 (3 x 64 + 7 x 8 + 7 = 255). No division is needed.
From 16, to 8
Input: ff
Output: 377
Other bases, and fractions that repeat in one base but not another
100 = 2 x 36 + 28, and the digit for 28 is the letter s (a = 10, so s = 10 + 18 = 28).
From 10, to 36
Input: 100
Output: 2s
One tenth ends in decimal but repeats in hexadecimal: 0.1 x 16 = 1.6 gives digit 1, then 0.6 x 16 = 9.6 gives digit 9 and a remainder of 0.6 again, so the 9 repeats.
From 10, to 16
Input: 0.1
Output: 0.1(9)
And the base matters in the other direction too: the base-3 number 0.1 is 1/3, which has no finite decimal form.
From 3, to 10
Input: 0.1
Output: 0.(3)
What goes wrong
These are inputs people really type. The messages are the tool's exact output, and each one is checked by a test.
A decimal comma
Many countries write one and a half as 1,5. Others use the comma for thousands (1,500). Because the same text means two different numbers, the tool refuses it rather than guess, and tells you to use a point.
From 10, to 2
Input: 1,5
Error: Character "," at position 2 is not a valid base-10 digit (digits are 0-9).
A typographic minus sign
Word processors and some web pages replace the hyphen in a negative number with a longer minus sign, U+2212. It looks right but it is a different character, and parseInt and Number in JavaScript also fail on it. The tool names it.
From 10, to 2
Input: −5
Error: The character at position 1 is the Unicode minus sign (U+2212), not a hyphen-minus.
Hex digits with the wrong "From" base
With "From base" left on 10, hexadecimal digits are not numbers. The message also explains that the letter is a digit in a higher base.
From 10, to 2
Input: FF
Error: Character "F" at position 1 is not a valid base-10 digit (digits are 0-9).
A 0x prefix with the wrong "From" base
A 0x prefix only means something when the "From" base is 16 (0b for 2, 0o for 8). In base 10 the x is just a wrong character, and the tool says so and explains the prefix.
From 10, to 2
Input: 0x1F
Error: Character "x" at position 2 is not a valid base-10 digit (digits are 0-9).
Two radix points
A version number such as 1.2.3 is not a number. The second point is reported at its position.
From 10, to 2
Input: 1.2.3
Error: A second radix point at position 4. A number has only one.
2^53 + 1 past the exact range of a JavaScript Number
This one is not an error; it is the case where other tools silently give a wrong answer. 9007199254740993 is 253 + 1, the first integer a 64-bit floating-point number cannot hold. JavaScript's Number("9007199254740993") and parseInt("9007199254740993") both give 9007199254740992, one less. This tool keeps the exact integer:
From 10, to 16
Input: 9007199254740993
Output: 20000000000001
In binary that is a 1, fifty-two zeros and a final 1 (54 bits). In hexadecimal it is 2, twelve zeros and a 1.
Limits & gotchas
- Input size. At most 5000 characters. Integers of that size convert exactly, using arbitrary-precision integers (JavaScript BigInt), so there is no rounding in the whole part.
- Fraction digits. A fraction that repeats is found exactly by remainder tracking. A fraction whose cycle is longer than the "Max fraction digits" setting (default 64, never more than 1024) is cut off and marked with
.... The digits shown are correct; they are not rounded up. - Steps shown. The division and multiplication tables show at most 40 rows. The total number of steps is still reported, and the answer does not depend on how many rows are shown.
- Bases 2 to 36 only. There is no base 1 (unary), no negative or fractional base, and no non-standard digit alphabet such as Base64. Base64 is an encoding of bytes, not a number base, so it is out of scope.
- Plain numbers only. Scientific notation (
1e3), fractions such as1/3, thousands separators and the words "infinity" or "NaN" are not accepted here. For floating-point values and the special cases, use the IEEE 754 converter. - Negative numbers are written with a minus sign. Two's complement bit patterns are a different representation, covered on the two's complement page; this page converts -5 to
-101, not to11111011. - Browsers. The page was tested in a current Chrome. It uses BigInt, which all current major browsers support.
FAQ
Why does 0.1 never end in binary?
Because 0.1 is the fraction 1/10, and 10 = 2 x 5. A fraction written in lowest terms has a finite expansion in a base only when every prime factor of its denominator is also a factor of the base. The base is 2, the denominator has the factor 5, so the binary expansion repeats forever: 0.1 is 0.0001100110011... with the block 0011 repeating. The tool shows this as 0.0(0011). The same fraction ends after one digit in base 10 and 0.1(9) in base 16 (the 9 repeats).
How do I convert binary to decimal, or decimal to binary, with this page?
Set "From base" to 2 and "To base" to 10, or the other way round. Binary to decimal is the "positional weights" table: every bit is multiplied by a power of two and the products are added (1010.101 is 8 + 2 + 0.5 + 0.125 = 10.625). Decimal to binary is the "repeated division" table for the whole part (divide by 2 and read the remainders from the bottom up) and the "repeated multiplication" table for the fractional part. This site has no separate binary-to-decimal and decimal-to-binary pages because they would run the same engine and show the same tables.
Why does my programming language disagree with this converter for big numbers?
Probably because it keeps the number in a 64-bit floating-point value, which holds integers exactly only up to 2^53 - 1 (9007199254740991 in JavaScript, MDN: Number). The input 9007199254740993 is 2^53 + 1. As a hexadecimal integer it is 20000000000001, and this tool gets it exactly because it uses arbitrary-size integers. In JavaScript, Number("9007199254740993") gives 9007199254740992 and parseInt("9007199254740993") does too.
What do the digits after "z" look like, and why is the limit 36?
The tool uses the digits 0-9 and then the letters a-z for the values 10 to 35, so the largest base it can write with single characters is 36. JavaScript's Number.prototype.toString(radix) and parseInt(text, radix) use the same alphabet and the same limit, which is why base 36 is a common "short ID" format. Upper and lower case letters mean the same digit here.
Why was my input rejected when it looks like a number?
The usual causes are a comma used as a decimal point ("1,5" is rejected, because the tool cannot tell a thousands separator from a decimal comma), a typographic minus sign (U+2212) instead of a hyphen, a hex number with the "From" base left on 10 ("FF" and "0x1F" are not base-10 numbers), or a second radix point. The message names the character and its position, and the page shows the exact messages for each of these under "What goes wrong".
Sources
- Wikipedia: Positional notation Used for: A number is written as digits multiplied by powers of the base, with the radix point separating the integer and fractional parts.
- Wikipedia: Repeating decimal Used for: In base 10 a fraction in lowest terms repeats if and only if its denominator has a prime factor other than 2 and 5; every repeating or terminating expansion is a rational number.
- MDN Web Docs: Number Used for: Integers are exact only between -(2^53 - 1) and 2^53 - 1 (MAX_SAFE_INTEGER); about 15 to 17 significant decimal digits.
- MDN Web Docs: parseInt() Used for: parseInt stops at the first character that is not a digit in the radix, returns NaN if the first character is not, and works on Numbers, not BigInt.
- MDN Web Docs: BigInt Used for: BigInt holds integers of arbitrary size; mixing BigInt and Number in arithmetic throws a TypeError.
Every document above was opened and read on 2026-10-02. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.
The conversion algorithms (repeated division for the whole part, repeated multiplication for the fraction, and detecting a repeat by an earlier remainder) are standard arithmetic. The tests check the results against JavaScript's own BigInt and Number.prototype.toString(radix) on thousands of random values, and against hand-worked expansions.