Decimal to Binary Converter

Repeated division by two

The standard method is to divide by 2 again and again, writing down the remainder each time, until the quotient reaches 0. The remainders are the bits of the answer — read from the last one up to the first.

Convert 156. 156 ÷ 2 = 78 remainder 0. 78 ÷ 2 = 39 remainder 0. 39 ÷ 2 = 19 remainder 1. 19 ÷ 2 = 9 remainder 1. 9 ÷ 2 = 4 remainder 1. 4 ÷ 2 = 2 remainder 0. 2 ÷ 2 = 1 remainder 0. 1 ÷ 2 = 0 remainder 1. Reading the remainders from the bottom up gives 10011100.

Check it the other way: the 1s are at positions 7, 4, 3 and 2, worth 128 + 16 + 8 + 4 = 156. The first remainder is always the rightmost bit, which tells you whether the number is odd — so 156, being even, ends in 0.

A second method: take away powers of two

If you know your powers of two, there is a method that builds the answer from the left. Find the largest power of two that fits, subtract it, and repeat with what is left. For 156: 128 fits, leaving 28. 64 and 32 do not fit. 16 fits, leaving 12. 8 fits, leaving 4. 4 fits, leaving 0. 2 and 1 do not.

Writing a 1 for each power used and a 0 for each skipped gives 1 0 0 1 1 1 0 0 — the same 10011100. This method is quicker for numbers near a power of two, and it is how most people convert small numbers in their heads once 1, 2, 4, 8, 16, 32, 64, 128, 256 and 512 are familiar.

Negative numbers in binary

With pencil and paper, −156 in binary is simply −10011100. Inside a computer there is no minus sign, and the number is stored in two's complement at a fixed width. The recipe: write the positive number at that width, flip every bit, then add one.

In 16 bits, 156 is 0000000010011100. Flipped, that is 1111111101100011. Adding one gives 1111111101100100, which is 0xFF64 — and 65,536 − 156 = 65,380 = 0xFF64, which confirms it. The two's complement panel does this at 8, 16, 32 and 64 bits and tells you when a value does not fit: −156 needs at least 9 bits, because a signed byte only reaches −128.

Decimal fractions, and why 0.1 never ends

Fractions convert by repeated multiplication instead of division. Multiply the fraction by 2; the whole-number part of the product (0 or 1) is the next bit, and you continue with what is left after the point. Here the bits are read from the top down. For 0.625: 0.625 × 2 = 1.25, bit 1; 0.25 × 2 = 0.5, bit 0; 0.5 × 2 = 1.0, bit 1, and nothing is left. So 0.625 is 0.101 in binary.

Try 0.1 and it never stops: 0.2, 0.4, 0.8, 1.6, 1.2, 0.4, 0.8… The pattern 0011 comes round for ever, giving 0.0001100110011… The converter detects the repeat and shows it as 0.0(0011). Only fractions whose denominator is a power of two — halves, quarters, eighths — end in binary.

This is the root of the famous floating-point surprise. A computer stores 0.1 rounded to 53 significant bits, so it is very slightly wrong, and 0.1 + 0.2 comes out as 0.30000000000000004 in JavaScript, Python and most other languages. For money, programs store whole cents (or paise) as integers for exactly this reason.

How many bits will a number need?

A positive whole number n needs floor(log₂ n) + 1 bits. In practice that means: up to 255 fits in 8 bits, up to 65,535 in 16 bits, up to 4,294,967,295 in 32 bits, and up to 18,446,744,073,709,551,615 in 64 bits. One more than each of those needs an extra bit — 256 is 100000000, nine digits.

These limits are why a byte holds 0 to 255, why old games had scores that wrapped at 65,535, and why a signed 32-bit timestamp counting seconds from 1970 runs out on 19 January 2038.

Mistakes to avoid

Reading the remainders top to bottom. That writes the number backwards — 156 would come out as 00111001, which is 57. The first remainder is the last bit.

Stopping too early. The division goes on until the quotient is 0, and the final step, 1 ÷ 2 = 0 remainder 1, always contributes the leading 1. Stopping at a quotient of 1 without recording it drops the most significant bit, halving the answer's size.