How to Convert Binary to Decimal

Every number you write down is already in a base. Writing 214 means two hundreds, one ten and four ones - the digits are the same three symbols in any order, and what gives them value is the column they sit in. Binary works exactly the same way, with one change: the columns go up by two instead of by ten, so there are only two digits to write with. Once you see that, converting between bases stops being a trick to memorise and becomes arithmetic you can do on paper. Here is how to do it by hand, and where to hand it to Base Converter instead.

What the columns are worth

In decimal the column values are powers of ten, read right to left: 1, 10, 100, 1000. In binary they are powers of two: 1, 2, 4, 8, 16, 32, 64, 128. A bit can only be 0 or 1, so each column is either counted or it is not. There is no other case, which is why the arithmetic is easy and why machines use it.

Hexadecimal, base 16, climbs faster: 1, 16, 256, 4096. It needs sixteen digits and there are only ten numerals, so a to f stand in for ten to fifteen.

Binary to decimal: add up the columns that are set

Write the place values above the bits, right to left, then add the ones with a 1 under them. Take 11010110:

• The bits, left to right: 1, 1, 0, 1, 0, 1, 1, 0
• The column each one sits in: 128, 64, 32, 16, 8, 4, 2, 1
• Keep only the columns with a 1 under them: 128 + 64 + 16 + 4 + 2
• Which comes to 214

That is the whole method. Columns with a 0 contribute nothing, so you are only ever adding a handful of numbers, each a power of two you can double your way to from 1.

Decimal to binary: divide by two and read the remainders upward

Going back, divide by two repeatedly and keep each remainder. The remainders are the bits, but they arrive backwards - the first is the rightmost bit - so read them bottom to top. Converting 214 back:

1. 214 / 2 = 107 remainder 0
2. 107 / 2 = 53 remainder 1
3. 53 / 2 = 26 remainder 1
4. 26 / 2 = 13 remainder 0
5. 13 / 2 = 6 remainder 1
6. 6 / 2 = 3 remainder 0
7. 3 / 2 = 1 remainder 1
8. 1 / 2 = 0 remainder 1

Reading the remainders from the bottom up gives 11010110, which is where we started. The same procedure works for any base - divide by the base instead of by two, and use the remainders as digits.

Hexadecimal is just binary in groups of four

Sixteen is two to the fourth power, and that one fact makes hex and binary interchangeable without any arithmetic at all. Four bits hold exactly the numbers 0 to 15, which is exactly one hex digit, so you can slice a binary number into groups of four from the right and convert each group on its own.

Split 11010110 into 1101 and 0110. The first is 8 + 4 + 1 = 13, which is d. The second is 4 + 2 = 6. So the number is d6 in hex - and checking against decimal, 13 times 16 plus 6 is 214, the same value again. This is the real reason hex is everywhere in computing: it is a shorthand for bits that a person can actually read, where one hex digit always means one nibble of four bits and a pair of them always means one byte.

Numbers with a point after them

Fractional columns carry on past the point, halving each time: 0.5, 0.25, 0.125, 0.0625. So 10.625 in binary is 1010.101, because 0.625 is 0.5 plus 0.125 - the first and third fractional columns - and the whole part 10 is 1010.

But a fraction that ends neatly in one base often runs forever in another, and this catches people out. One tenth is a perfectly tidy 0.1 in decimal, and in binary it never terminates: it runs 0.0001100110011... with 0011 repeating for as long as you care to write it. The rule is that a fraction terminates in a given base only when the bottom of the fraction is built from that base's own prime factors. Ten is two times five, so halves, quarters, fifths and tenths all end cleanly in decimal. Two only has itself, so only halves, quarters and eighths end cleanly in binary - a fifth or a tenth cannot.

This is why a program can add 0.1 and 0.2 and get 0.30000000000000004: it never had a tenth, only the nearest binary approximation of one.

Why most online converters go wrong on big numbers

There is a bug so widespread in small conversion tools that it is worth knowing how to spot. The usual one-line implementation reads the input with a function that hands back an ordinary floating point number, and a floating point number holds whole numbers exactly only up to 9,007,199,254,740,992 - two to the power 53, roughly nine quadrillion. Above that, values are rounded to the nearest representable one before anything is even converted.

The failure is not a small one at the edges. Ask such a converter for ffffffffffffffff - sixteen f characters, the largest unsigned 64-bit value - in binary, and it answers with a 1 followed by 64 zeros. The correct answer is 64 ones. Every single bit is wrong, and there is one digit too many, because the value was rounded up to the next power of two on the way in and nothing downstream knew.

That range covers most of what people actually paste into a base converter: 64-bit hashes, database and snowflake IDs, checksums, register dumps, 128-bit UUIDs. If you want to check a tool before you trust it, give it 9007199254740993 - two to the 53rd plus one - and ask for decimal back. A converter that rounds will hand you 9007199254740992, one short.

Letting the tool do it

Base Converter does all of the above at once: type a number in any base from 2 to 36 and binary, octal, decimal and hex all appear together, with a box to add any other base you need. It runs on arbitrary-precision integers, so length is not a limit and nothing is rounded on the way through. Fractions are expanded exactly, with a repeating run shown in brackets - 0.1 in decimal comes out as 0.0(0011) in binary rather than being quietly truncated into a number that looks exact and is not.

Negative numbers get a two's complement panel underneath - the form a computer actually stores them in at 8, 16, 32 and 64 bits - and a value too large for a width is reported rather than silently wrapped. Spaces, underscores and commas are ignored, so a grouped value out of a spreadsheet or a hex dump pastes straight in. Everything runs in your browser, so an internal ID never leaves your machine.