Skip to main content
CalcMax

Binary to Decimal Converter

Result

11

Decimal

Place values
8 + 2 + 1

A binary to decimal converter turns a number written in base two into the same number written in base ten. The value does not change — only its notation does. Positional notation is the whole of it: a digit is worth its face value multiplied by a power of the base, and the binary number system simply takes two as that base. You already know the rule from decimal: the number 352 is three hundreds plus five tens plus two ones, because each position is worth ten times the one to its right. In binary the positions are worth two times the one to its right instead, so they run 1, 2, 4, 8, 16, 32 and so on, and the digits are only ever 0 or 1. Converting is then a matter of adding up the positions that hold a 1 and ignoring the ones that hold a 0: 1011 is 8 plus 2 plus 1, which is 11. That sum is what this page prints underneath the answer, one term per set bit, because it is the step people get wrong when they do it in their head — skipping a position, or starting the count at the wrong end. The digits are read from the right, not the left: the rightmost bit is always worth 1, whatever the length of the number.

The place value of every bit in a byte, from the leftmost down to the rightmost

BitPowerValue
72⁷128
62⁶64
52⁵32
42⁴16
32³8
22²4
12¹2
02⁰1

This is the ruler the conversion is carried out with, and it is fixed: it does not change when the input above it does, so it is not a contradiction when the two seem to disagree. The panel answers the number that was typed; the table answers the more general question of what each position in a byte is worth, which is the question that comes first when you have no number in hand yet. Read the rows downward as halving each time and upward as doubling, and the pattern explains itself: the rightmost bit is worth 1 because it is the ones position, the bit beside it is worth 2 because the base is two, and every step left doubles. The reason it stops after eight rows is that a byte is where the values people actually convert live — a status flag, a colour channel, a permission mask — and a table running to the fifty-third bit would be a wall of numbers nobody reads. The set bits of a number are read off this table and added, so the table and the sum printed above it are describing the same eight positions in two different ways. One warning about direction: the bit numbers here are counted from the right, so bit 0 is the last digit, and a document that counts its bits from the left will disagree with this table on every row while meaning the same thing.

Formula

1011 = 1×2³ + 0×2² + 1×2¹ + 1×2⁰ = 8 + 2 + 1 = 11

binary
The number to read, written in base two. Its digits are 0 and 1 and nothing else, and the value of the whole number depends on where each digit sits rather than on how many digits there are
2ⁿ
The place value of a position: two raised to the power of how far that position is from the right-hand end, counting the rightmost as position zero. The sequence is 1, 2, 4, 8, 16, 32, 64, 128 and each step is double the one before it
digit × 2ⁿ
A single term of the sum. Since the digit is either 0 or 1 the multiplication never changes anything — a 1 contributes its place value whole and a 0 contributes nothing at all, which is why the conversion reduces to picking out the positions that hold a 1
Σ
The addition of every term. It is the whole conversion: add the place values of the set bits and the total is the number in decimal
8 + 2 + 1
The sum shown with the zero terms dropped, which is how it is written by hand. 1011 has ones in the 8, 2 and 1 positions and a zero in the 4 position, so the 4 never appears — seeing it missing is the point, since that is the step people lose track of
53 bits
How long the input may be: fifty-three binary digits, which is 9007199254740991. It is the width at which a machine stops being able to tell neighbouring whole numbers apart, so a longer input cannot be read exactly and is refused rather than guessed at

This is a conversion people need in both directions of reading. The forward case is a value that arrived in binary and has to be understood: a status byte printed by a debugger, the flag column of a hardware register, a bitmask in a configuration file, the output of a network tool, or a homework exercise where the answer is supposed to be written in base ten. The backward case is the power-of-two reasoning that hides behind ordinary numbers — whether a number is a power of two, what the next power of two above some figure is, how many bits it takes to store a value, or how large a range a bus of a given width can address — and all of those questions are answered by looking at which positions are set. Programmers meet the same sum when working out a subnet mask, packing several small values into one integer, or checking which of a set of options a stored number has enabled. The place values output is what makes the page useful as a teaching tool as well: the carry rules and the position weights are the two things that look arbitrary until the sum is written out, and having the page write that sum for whatever was typed turns a worked example in a book into a check on your own attempt. Anyone reading a binary number by hand, and anyone who wants to know why the answer is what it is rather than only what it is, gets the same thing from it.

Worked examples

  1. Reading 1011

    1. Write the place values under the four digits, from the right: 1, 2, 4, 8
    2. Keep the digits that are 1 and drop the ones that are 0: this leaves 8, 2 and 1
    3. The 4 position holds a 0, so it contributes nothing and does not appear in the sum
    4. Add them: 8 + 2 + 1 = 11

    The default, and the one that shows the missing term: 1011 has a zero in the fours place, so the sum reads 8 + 2 + 1 rather than 8 + 4 + 2 + 1. Reading the digits as decimal digits instead would give one thousand and eleven, which is the single most common way this conversion goes wrong.

  2. Reading a full byte, 10110010

    1. Eight digits means the place values run from 128 down to 1
    2. The set positions are 128, 32, 16 and 2
    3. Add them: 128 + 32 = 160, plus 16 is 176, plus 2 is 178
    4. The largest value a byte can hold is 11111111, which is 255

    Worth working through once because a byte is the width almost every binary value in practice arrives at, and knowing that the leftmost bit is worth 128 and the rightmost is worth 1 is what makes a byte readable at a glance. The same eight digits would be quite different read from the other end, so the direction is not a detail.

  3. Leading zeros do not change the value

    1. The four leading zeros sit in the 128, 64, 32 and 16 positions
    2. A zero contributes nothing wherever it sits, so those positions drop out of the sum
    3. What remains is the same 8 + 2 + 1 as before, giving 11

    Padding a value out to a fixed width is normal — a byte is written 00001011 rather than 1011 when the width matters — so the converter has to accept both forms and give the same answer for each. It does, and the sum it prints is identical because the leading zeros never enter it.

  4. Reading a negative value, -1011

    1. The minus sign is not part of the binary number — it is a sign in front of it
    2. Read the digits as before: 1011 is 8 + 2 + 1 = 11
    3. Put the sign back: the value is -11

    The sign is kept outside the digits rather than folded into them, because there is no fixed width here to fold it into. A processor storing -11 in eight bits would write 11110101, which is a different string of digits entirely and depends on knowing that the width is eight. This page has no width, so the sign stays a sign.

Limitations

This page reads whole binary numbers only. There is no binary point, so 1.01 is not accepted and cannot be converted — a fractional reading would need a second rule about where the point sits, and that rule would have to be stated per input rather than assumed. The input may be at most fifty-three digits long, which is 9007199254740991 in decimal; longer values cannot be held exactly by a machine and are refused rather than rounded. Leading zeros are accepted and ignored, so 00001011 and 1011 are the same number, and the sum printed for them is identical. A minus sign in front is accepted and carried through to both outputs. The page converts from binary to decimal; the opposite direction is a separate page linked below, and hexadecimal readings are on another one. It does not do arithmetic and it does not do bitwise operations — there is no AND, OR, XOR or shift here.

Frequently asked questions

How do I convert binary to decimal by hand?
Write the place values under the digits, starting at 1 on the right and doubling each time you move left — 1, 2, 4, 8, 16 and so on. Then keep the values that sit under a 1 and throw away the ones that sit under a 0, and add what is left. For 1011 that gives 8, 2 and 1, which is 11. The two ways this goes wrong are reading the digits from the left instead of the right, and adding a place value that holds a zero — both of which the sum printed on this page will show you, because it lists only the terms that count.
Why does the answer not include the place values with a zero under them?
Because they contribute nothing, and writing them out would bury the part that matters. Zero times any place value is zero, so a term like 0×4 can be dropped without changing the total. The sum is shown as 8 + 2 + 1 rather than 8 + 0 + 2 + 1 precisely so that the missing four is visible: seeing which positions are absent is how you check that you lined the digits up correctly in the first place.
Does a leading zero change the number?
No. Leading zeros sit in positions that contribute nothing, exactly as they do in decimal, where 007 is still seven. 00001011 and 1011 are the same number and this page gives the same two outputs for both. Padding to a fixed width is common when the width carries meaning — a byte is usually written with all eight digits — so accepting the padded form is necessary, not a convenience.
What is the largest binary number I can convert here?
Fifty-three digits, which is 9007199254740991 in decimal. The limit is not a choice made by this page: it is the width at which a machine number stops being able to tell neighbouring whole numbers apart, so a longer input could not be read exactly and the page would have to print something that looks like an answer and is not one. A longer input is refused with a message instead. This matters more here than on the arithmetic pages, because converting sounds like reading and reading sounds unlimited.
Is this the same as dividing by two repeatedly?
It gives the same answer by a different route. Repeated division by two produces the digits from the right, which is the method to use in the other direction — going from decimal to binary. Going from binary to decimal, the place value sum is shorter, because the digits are already known and only their weights have to be added. Both are correct; the sum is what this page prints, because it is the one you can check at a glance.
Can I convert a binary number with a fractional part?
Not here. This page reads whole numbers, so a binary point is rejected rather than guessed at. Fractions in binary are perfectly well defined — the positions to the right of the point are worth a half, a quarter, an eighth and so on — but a page that accepted them would need to decide how many of them to show and how to round the last one, and this family of pages works in whole numbers throughout. Keeping that boundary in the same place on every page of the group means the same input is never accepted by one page and refused by another.

References

Related calculators

Decimal to Binary ConverterHalve a decimal integer into binary, with each step shown.Binary to Hex ConverterConvert binary to hexadecimal, four bits at a time.Binary CalculatorAdd, subtract, multiply and divide binary numbers.Hex to Decimal ConverterAdd up the powers of sixteen a hex number is made of.Place Value CalculatorThe place value of every digit in a number.