Skip to main content
CalcMax

Binary Calculator

Result

10001

Binary

Decimal
17
Hexadecimal
11
Remainder
0

A binary calculator adds, subtracts, multiplies and divides numbers written in base two, and shows the answer in binary, decimal and hexadecimal at once. Base two uses only the digits 0 and 1, and the arithmetic is the same arithmetic you already know — the only thing that changes is where the carry happens. In decimal, 9 plus 1 carries because ten is the base; in binary, 1 plus 1 carries because two is. That single fact is the whole of binary addition, and subtraction, multiplication and division all follow from it in the way you would expect. The answer is printed three times because the three readings are good for different things: the binary is what you came for, the decimal is what you can check at a glance, and the hexadecimal is the same bits grouped four at a time, which is how anyone writing machine code reads them. Division is integer division, so the remainder gets a row of its own instead of disappearing into a decimal point.

Formula

1011 + 110 = 10001 (11 + 6 = 17)

1011
The first number, written in base two. Reading it as base two is what makes it eleven — the same digits read as decimal would be one thousand and eleven, which is exactly the mistake this page exists to prevent
+ − × ÷
The operation. It works digit by digit exactly as it does in decimal, with ten replaced by two everywhere a carry or a borrow happens
1 + 1 = 10
The only fact in binary arithmetic that is not already familiar. Two ones make a zero with a one carried into the next place, because the digits run out after one. Three ones make 11 — a one in the answer and a one carried
sum of digit × 2ⁿ
How the decimal reading is produced: every binary digit multiplied by its place value and the results added. It is how 10001 comes out as seventeen, and it is the only route between the binary answer and the decimal one
remainder
What is left when a division does not come out exactly. Dividing 1011 by 10 gives 101 with 1 left over, because eleven is five twos and one more. The remainder is always shown, and it is zero for the three operations that cannot leave one
53 bits
How wide an input this page accepts: up to 9007199254740991, which is a one followed by fifty-three digits in binary. Past that width a machine number stops being able to tell its neighbours apart, and the arithmetic would quietly stop being exact

Anyone reading or writing binary needs this page for the same reason they need a decimal calculator: the arithmetic is not hard, but doing it by hand is slow and the mistakes are invisible. The everyday uses are reading a hardware register or a bitmask — 1011 AND something, or which flags a status byte has set — and checking a value that has been printed in binary by a compiler, a debugger or a network tool. Subnet masks, permission bits on a file, the flag column of a CPU status register and the pin states of a microcontroller are all binary numbers that people need to do arithmetic on, and the hexadecimal reading next to the answer is the form those values are actually written in when they are documented. The other use is learning: the carry rule is the thing everyone gets wrong on paper exactly once, and typing 1011 plus 110 and seeing 10001 appear is a faster way to fix it than a worked example in a book. Students working through number bases by hand, and anyone converting a listing of machine code back into something checkable, will find the decimal and hexadecimal readings do most of the work.

Worked examples

  1. Adding 1011 and 110

    1. Line the two numbers up on the right: 1011 and 0110
    2. Rightmost column: 1 + 0 = 1
    3. Next column: 1 + 1 = 10, so write 0 and carry 1
    4. Next column: 0 + 1 + the carried 1 = 10, so write 0 and carry 1
    5. Leftmost column: 1 + the carried 1 = 10, so write 0 and carry 1 into a new place
    6. The result reads 10001, which is 16 + 1 = 17 in decimal

    The page's opening example, and the fastest way to see the carry rule at work: the sum is longer than either input because the last carry needed a place of its own. The decimal reading of 17 is the check — 11 plus 6 really is 17 — and the hexadecimal 11 is the same bits grouped four at a time, which is why it happens to look like the decimal eleven. That coincidence disappears as soon as the numbers get bigger.

  2. Dividing 1011 by 10

    1. This is eleven divided by two, so the answer is five with one left over
    2. Five in binary is 101, and one is 1
    3. The page reports the quotient as 101 and the remainder as 1 rather than printing 101.1

    The example that shows why the remainder row exists. Printed as a quotient alone, 101 would say that eleven divided by two is five, and the row below it is what makes the statement true. There is a second reason not to reach for a decimal point here: the moment a result has a fractional part, the arithmetic can stop terminating — one divided by three in binary runs forever — and this page's inputs and outputs are whole numbers throughout.

  3. Subtracting 1011 from 110

    1. This is six minus eleven, so the answer is negative
    2. The difference is five, and the sign is carried in front of the result
    3. Five is 101, so the answer is -101

    Nothing here uses two's complement, the scheme a processor uses to store negative numbers. The minus sign is kept as a sign on the front of the number, which is the form a person writing on paper uses and the form that stays readable when the value is printed next to its decimal and hexadecimal readings. A machine's representation of the same value would be a fixed-width pattern of bits, and that width is not something this page has.

Limitations

This page works on whole numbers only. There is no binary point and no fractional binary, so 1.01 is not accepted — which also means a division that does not come out exactly gets a quotient and a remainder rather than a decimal expansion, and the quotient is truncated towards zero rather than rounded. Inputs are limited to 9007199254740991, a one followed by fifty-three binary digits; past that the arithmetic can no longer be guaranteed exact, and an input that large is refused rather than answered approximately. Results are held to the same ceiling, so a multiplication that overflows it reports an error instead of a wrong number. Negative numbers are written with a minus sign in front rather than in two's complement, and no fixed bit width is offered or assumed: 1011 is four bits here, not the low four bits of a register. Division by zero is refused.

Frequently asked questions

Why does 1 + 1 equal 10 and not 2?
Because there is no digit for two in base two. The digits are 0 and 1 and then the column runs out, exactly as the units column runs out after 9 in decimal. So two ones make a zero in that column and carry a one into the next one, which is written 10 — and that is the same statement as the decimal 9 + 1 = 10, with the base changed. Three ones make 11: a one in the answer and a one carried.
Why is there always a remainder row when I add or multiply?
Because the results panel is a fixed list rather than a list that grows and shrinks with the operation you picked, and a row that appeared and vanished would be harder to read than a row that is always in the same place. Subtracting, adding and multiplying cannot leave a remainder in whole numbers, so it reads 0 there — that zero is the row saying the operation did not leave one, not a failure to compute it. Division is the only operation here that can leave one, and the row is what keeps a truncated quotient from looking like an exact answer.
What is the largest number I can enter?
9007199254740991, which is fifty-three ones in binary, or 1FFFFFFFFFFFFF in hexadecimal. The limit is the width at which a machine stops being able to tell neighbouring whole numbers apart, so past it the arithmetic would silently stop being exact — the result would look like a number and would not be one. An input wider than that is refused with a message rather than truncated or rounded, and a result that overflows the same ceiling is refused too.
Can I do subtraction and get a negative answer?
Yes. Put the larger number in the second box and the answer comes back with a minus sign in front, in all three readings. This is not two's complement, the representation a processor uses when it stores a negative number in fixed-width bits — it is the sign-on-the-front form, which is what you would write on paper and what stays legible next to a decimal and a hexadecimal reading. No bit width is assumed, so a negative answer is not wrapped into a pattern of ones.
Why is division not exact?
Because this page works on whole numbers, so a division that does not come out evenly gives the quotient truncated towards zero plus the remainder. Eleven divided by two is five remainder one, and the page reports 101 and 1 rather than 101.1. That is a deliberate choice rather than a gap: the moment a result has a fractional part the arithmetic can fail to terminate — one divided by three in binary is a repeating expansion — and a page that quietly rounded it would print a number that is not the answer.
What is the hexadecimal reading for?
It is the same value grouped four bits at a time, which is how people who write machine code read binary. A byte is eight bits and therefore exactly two hexadecimal digits, so FF, 2A and B2 are the forms that appear in documentation, debuggers and data sheets. Converting between binary and hexadecimal is not really a calculation at all — it is a regrouping — which is why the reading is free here.

References

Related calculators

Hex CalculatorArithmetic on hexadecimal numbers, with decimal equivalents.Binary to Decimal ConverterConvert binary to decimal, with the place values.Binary to Hex ConverterConvert binary to hexadecimal, four bits at a time.Decimal to Binary ConverterHalve a decimal integer into binary, with each step shown.