Converting a decimal number to binary is one repeated move: divide by 2 and write down the remainder. Do it until the quotient reaches 0, then read the remainders from the last one to the first. That is the whole method, and it works for every whole number, from 5 to 5,000. This guide works the method slowly, explains why reading backwards is correct, handles the two cases that trip people up — zero and fractions — and shows how to check any answer by converting it back.

The method: divide by 2, keep the remainders

Binary is base 2. Where decimal uses ten digits, 0 to 9, and each place is worth ten times the place to its right, binary uses two digits, 0 and 1, and each place is worth twice the place to its right. The places, from the right, are 1, 2, 4, 8, 16, 32, 64, 128, and so on. A binary number such as 1011 means 1 eight plus 0 fours plus 1 two plus 1 one, which is 11 in decimal. Converting from decimal to binary is therefore a question of breaking the decimal number into a sum of powers of 2, with each power used at most once.

The divide-by-2 method does exactly that, one power at a time. Take the decimal number and divide it by 2. Write down the quotient and the remainder. The remainder is either 0, if the number was even, or 1, if it was odd, and it is the rightmost bit of the answer — the ones place. Now divide the quotient by 2 and record that remainder, which is the twos place. Keep going: each division peels off the next bit, from right to left, until the quotient is 0 and there is nothing left to divide. The remainders, read from the last division back to the first, are the binary number. The procedure never needs a decision or a guess; the only skill is careful division, and the only place an error can enter is a wrong quotient or remainder on one line.

Try it on a small number first. Convert 13. Divide 13 by 2: quotient 6, remainder 1. Divide 6 by 2: quotient 3, remainder 0. Divide 3 by 2: quotient 1, remainder 1. Divide 1 by 2: quotient 0, remainder 1. Stop, because the quotient is 0. The remainders in the order they were produced are 1, 0, 1, 1. Read them backwards — 1, 1, 0, 1 — and the answer is 1101. Check: 8 + 4 + 0 + 1 = 13. The method is mechanical, and the check takes seconds, which is why the two belong together: convert with the division, verify with the expansion.

Worked example: 64 to binary, line by line

Powers of 2 are the cleanest conversions, and 64 is worth working in full because it shows what the method does at each step. 64 is even, so the first remainder is 0. Halving repeatedly: 64, 32, 16, 8, 4, 2, 1, 0. Seven divisions, seven remainders. Every division except the last leaves remainder 0, and the last division, 1 divided by 2, leaves remainder 1. Read the remainders backwards and only the final 1 survives at the front, followed by six zeros: 1000000. That is a 1 in the 64s place and zeros everywhere else, which is exactly what 64 is. Counting the digits confirms the pattern: 64 needs 7 bits, because 2 to the power of 6 is 64, and the leftmost bit sits in the 64s place.

Reading the remainders from the last row to the first gives 1000000.

Notice what the table makes visible: the quotient column is just the halving sequence, and the remainder column is all zeros until the final 1. For any power of 2 the table looks the same — a column of zeros topped by one 1 — and the answer is a 1 followed by zeros, with the number of zeros equal to the exponent. 2 is 10, 4 is 100, 8 is 1000, 16 is 10000. If your conversion of a power of 2 produces anything else, the error is in the table, not the method. Powers of 2 are also the fastest way to sanity-check a conversion in the other direction: if the answer claims a number just below a power of 2, such as 63, every bit should be 1, because 63 is 32 + 16 + 8 + 4 + 2 + 1, which is 111111.

Worked example: 37 to binary

Now a number that is not a power of 2, worked the same way. Convert 37. Divide 37 by 2: quotient 18, remainder 1. Divide 18 by 2: quotient 9, remainder 0. Divide 9 by 2: quotient 4, remainder 1. Divide 4 by 2: quotient 2, remainder 0. Divide 2 by 2: quotient 1, remainder 0. Divide 1 by 2: quotient 0, remainder 1. The remainders in order are 1, 0, 1, 0, 0, 1. Read backwards: 100101. Check by expansion: 32 + 0 + 0 + 4 + 0 + 1 = 37. The check is not a formality; it is how you catch the single most common error, a remainder written in the wrong row, before it costs marks or breaks code.

There is a second way to see the same answer, and it is worth knowing because it is faster for numbers near a power of 2. Find the largest power of 2 that fits in the number, subtract it, and repeat with what is left. For 37, the largest power of 2 that fits is 32, leaving 5. The largest power of 2 in 5 is 4, leaving 1. The largest power of 2 in 1 is 1, leaving 0. The powers used are 32, 4, and 1, so the bits in the 32, 16, 8, 4, 2, and 1 places are 1, 0, 0, 1, 0, 1: 100101, the same answer. The two methods agree because they are the same mathematics seen from opposite ends — division peels bits off from the right, subtraction collects them from the left — and when they disagree, one of them has an arithmetic slip. Use whichever feels natural, and use the other to check.

Why you read the remainders backwards

The backwards reading is the part that feels arbitrary until you see why it is forced. Each division by 2 asks one question: is the number odd or even right now? The first division answers it for the original number, and its remainder is the ones bit, the least important bit. The next division answers it for the number with that bit removed, and its remainder is the twos bit. Each step moves one place to the left. So the remainders arrive in order of increasing importance: ones first, then twos, then fours. But we write numbers with the most important digit on the left. Reading the remainders backwards is simply putting them in written order, most important first. Reading them forwards gives the bit-reversed number, which is a different number entirely — 37 forwards is 101001, which is 41, not 37.

The same idea explains why the process stops when the quotient reaches 0. The quotient is what is left after the current bit has been taken out. When it reaches 0, every bit has been taken out, and the last remainder is the leftmost 1. There is no need for a final step, and adding leading zeros after that changes nothing: 00100101 is still 37, just as 037 is still 37 in decimal. Leading zeros are harmless but pointless, and the convention is to drop them. Trailing zeros, by contrast, matter enormously: 1001010 is 74, double 37, because every bit has shifted one place left. If your answer ends in a zero that the remainders do not support, you have almost certainly read one row too many or too few.

Larger numbers and the bit count

The method does not change as numbers grow; only the table gets longer. Convert 255. Halving: 255, 127, 63, 31, 15, 7, 3, 1, 0. Every division leaves remainder 1, because every quotient in the chain is odd, so the answer is eight 1s: 11111111. That is 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255, and it is the largest number that fits in 8 bits. One more, 256, needs a ninth bit and becomes 100000000. The boundary numbers are worth memorising as landmarks: 8 bits hold 0 to 255, 16 bits hold 0 to 65,535, and 32 bits hold 0 to 4,294,967,295. Each extra bit doubles the range, which is why a single bit matters so much in computing: the difference between 8 bits and 9 bits is the difference between 256 values and 512.

To find how many bits a number needs before converting, find the smallest power of 2 that is larger than the number. 100 needs 7 bits, because 128 is the first power of 2 above 100. 1,000 needs 10 bits, because 1,024 is the first power of 2 above 1,000. As a worked example, convert 100: the remainders, in order, are 0, 0, 1, 0, 0, 1, 1, giving 1100100 when read backwards. Check: 64 + 32 + 0 + 0 + 4 + 0 + 0 = 100. If your conversion of 100 produces 8 bits, the extra leading bit must be 0; if it produces 6 bits, one bit is missing and the value cannot reach 100. The bit count is a free error check that costs nothing and catches exactly the dropped-row mistakes the division method is prone to.

Each row was produced by the divide-by-2 method and checked by expansion.

Decimal fractions: the multiply-by-2 method

Whole numbers divide by 2. Fractions multiply by 2. To convert the fractional part of a decimal number, such as the .625 in 5.625, multiply the fraction by 2. If the result is 1 or more, write 1 and carry only the fractional part forward; if it is less than 1, write 0 and carry the whole result forward. Repeat until the fractional part becomes 0 or you have enough bits. The bits are read forwards, in the order produced, because the first multiplication finds the halves bit, the next finds the quarters bit, and so on — the reverse of the whole-number case, where the first division finds the least important bit.

Convert 0.625. Multiply by 2: 1.25, so write 1 and carry 0.25. Multiply 0.25 by 2: 0.5, so write 0 and carry 0.5. Multiply 0.5 by 2: 1.0, so write 1 and carry 0. The bits in order are 1, 0, 1, so 0.625 is 0.101 in binary. Check: one half plus zero quarters plus one eighth is 0.5 + 0.125 = 0.625. Not every fraction terminates. Convert 0.1: the multiplications cycle 0.2, 0.4, 0.8, 0.6, 0.2, and the bits repeat 00011 forever, which is why 0.1 in binary is the repeating 0.0001100110011 and why computers, which must stop somewhere, cannot store 0.1 exactly. That single fact explains the famous 0.1 + 0.2 result on the Decimal Calculator page: the arithmetic is exact in decimal, but the binary storage of the inputs is already an approximation.

For a mixed number, convert the two parts separately and join them with the binary point. 5.625 is 101 from the whole-number method and .101 from the fraction method, giving 101.101. Negative numbers are a separate convention, not a separate conversion: the magnitude converts exactly as above, and the sign is carried by the representation in use — a minus sign in school mathematics, or two complement in computing, where the leftmost bit carries the sign and the value is formed by inverting the bits and adding 1. This guide stays with magnitudes, because the conversion itself is identical; the sign convention is a property of the system reading the bits, not of the conversion.

Checking your answer by converting back

Every conversion deserves a check, and the check is the expansion: write the place values above the bits, multiply, and add. For 100101, the places are 32, 16, 8, 4, 2, 1, and the sum is 32 + 4 + 1 = 37. The expansion is also the fastest way to convert in the opposite direction, binary to decimal, which is a useful skill in its own right: read the bits, add the place values of the 1 bits, ignore the 0 bits. 11010 is 16 + 8 + 2 = 26. There is no division involved, and no backwards reading, because the written order already is the order of importance.

Two quick checks catch most errors before the full expansion. First, the parity check: the rightmost bit must match the parity of the original number — 1 if it was odd, 0 if it was even. If 37 converts to something ending in 0, it is wrong. Second, the size check: the leftmost bit must sit in the largest power-of-2 place that fits, so the bit count must match the landmark rule above. A conversion that passes both checks can still be wrong in a middle bit, which is why the full expansion remains the gold standard, but a conversion that fails either check is certainly wrong, and finding that out in two seconds beats finding it after the answer has been used.

The four mistakes that produce a wrong answer

First, reading the remainders forwards. It produces a plausible-looking binary number that is wrong, and it is the most common error by a wide margin. Guard against it by always writing the remainders in a column and drawing an arrow from the bottom of the column to the top, or by writing the answer from the last row upward as you go. Second, stopping one division early, which drops the leftmost 1 and halves the value. The rule is absolute: stop only when the quotient is 0, and include that final remainder. Third, a division slip in the middle of a long table — 91 halved to 44 instead of 45, for example — which corrupts every bit after it. Guard against it with the parity check on each row: the remainder is 1 exactly when the number being divided is odd.

Fourth, mixing the two methods: dividing the whole part and multiplying the fraction part is correct, but applying division to a fraction, or multiplication to a whole number, produces nonsense. Keep the two parts of a mixed number in separate columns until both are done. A fifth, quieter mistake is treating 0 carelessly: 0 converts to 0, a single bit, because there is nothing to divide and the quotient is 0 from the start. Writing it as an empty answer, or as 00, invites confusion in any system that reads it. Finally, remember that the Decimal Calculator on this site works in exact decimal arithmetic, while binary conversion is about representation: converting 0.1 to binary and back will not return exactly 0.1 in a finite number of bits, and that is a property of binary, not a bug in the calculator. Work a conversion by hand, check it by expansion, and the method will never surprise you.

Frequently asked questions

What is the fastest way to convert a decimal number to binary?

Use the divide-by-2 method: divide by 2, write the remainder, repeat on the quotient until it reaches 0, then read the remainders backwards. For numbers near a power of 2, the subtraction method is faster: subtract the largest power of 2 that fits, repeat on the remainder, and mark a 1 in each place you used. Both methods give the same answer, and the expansion check confirms it.

How do you convert 10 to binary?

Divide 10 by 2 to get quotient 5 remainder 0, divide 5 by 2 to get quotient 2 remainder 1, divide 2 by 2 to get quotient 1 remainder 0, and divide 1 by 2 to get quotient 0 remainder 1. Reading the remainders backwards gives 1010. Check: 8 plus 2 is 10. The number 10 needs 4 bits because 16 is the smallest power of 2 above it.

Why is binary read from right to left when converting back?

Because the rightmost bit is the ones place and each place to the left doubles in value. The divide-by-2 method finds the ones bit first, so its remainders arrive least important first and must be reversed into written order. The expansion check reads the written number in its natural order, adding the place value of each bit that is 1.

Can every decimal number be converted to binary exactly?

Every whole number can, exactly, in a finite number of bits. Decimal fractions cannot always be converted exactly: fractions whose denominator is a power of 2, such as 0.5 or 0.625, terminate, but fractions such as 0.1 repeat forever in binary, just as one third repeats forever in decimal. A computer stores only a fixed number of bits, so it rounds the repeating pattern, which is why decimal fractions can lose exactness in binary storage.

What is 255 in binary, and why does it matter?

255 is 11111111, eight 1 bits. It is the largest value that fits in 8 bits, because 128 plus 64 plus 32 plus 16 plus 8 plus 4 plus 2 plus 1 equals 255. One more, 256, needs a ninth bit. The 0 to 255 range is the range of a byte, the basic unit of computer storage, which is why 255 appears constantly in computing, from colour values to network addresses.

How do I convert a decimal fraction such as 0.75 to binary?

Multiply the fraction by 2 repeatedly and record 1 when the result reaches 1 or more, 0 when it does not, carrying only the fractional part forward. For 0.75: doubling gives 1.5, so record 1 and carry 0.5; doubling 0.5 gives 1.0, so record 1 and stop. The bits in order are 1 and 1, so 0.75 is 0.11 in binary: one half plus one quarter. Read fraction bits forwards, unlike whole-number remainders.