Binary Multiplication Calculator: Long Multiplication When You Only Have 0 and 1
About the Author
Marko Šinko
Co-Founder & Lead Developer, AI Math Calculator
A binary multiplication calculator exists to spare you the bookkeeping, not the concept — because the concept is the easiest part of binary arithmetic. There is no times table to memorise. There are exactly four products, and three of them are zero:
0 × 0 = 0 0 × 1 = 0 1 × 0 = 0 1 × 1 = 1
That is the whole multiplication table. Base 10 asks you to know 100 of these; base 2 asks for four, and multiplying a row by a digit reduces to a question with a yes/no answer — copy it, or don’t. So if the arithmetic is trivial, why do people get binary multiplication wrong so consistently? Because the difficulty moved. It is no longer in the multiplying. It is in the shifting, and in the addition at the end, where three or four 1s can pile into one column and produce a carry bigger than anything binary addition ever generates.
Why the Hard Part Isn’t the Multiplying
Work out 1011 × 110 by hand. In decimal that is 11 × 6, and you would reach for a memorised fact. In binary you never multiply anything — you walk the multiplier’s bits from the right and ask one question per bit:
- Bit 0 of 110 is 0 → write nothing
- Bit 1 is 1 → copy 1011, shifted one place left: 10110
- Bit 2 is 1 → copy 1011, shifted two places left: 101100
Stack them and add:
1011 × 110 ------ 0000 10110 101100 ------ 1000010
1000010₂ is 66, and 11 × 6 = 66. The point worth holding onto is that no step in the middle required arithmetic knowledge. Copy or don’t copy, shift, add. Everything a multiplication algorithm does in binary is bookkeeping, which is precisely why it maps so cleanly onto hardware — and why the calculator above prints the zero rows in grey instead of omitting them. Drop them and the shift positions of the surviving rows stop being obvious, which is the single most common source of hand-calculation errors.
Each Shift Left Doubles the Number
Shifting is not a formatting convention. In base 10, moving a digit one place left multiplies it by 10. In base 2 it multiplies by 2, and that is the entire reason the staircase works.
| Binary | Decimal | Operation |
|---|---|---|
| 1011 | 11 | starting value |
| 10110 | 22 | shift 1 left = × 2 |
| 101100 | 44 | shift 2 left = × 4 |
| 1011000 | 88 | shift 3 left = × 8 |
Read the 1011 × 110 example again with those values substituted and it says 22 + 44 = 66. The staircase is not a trick for getting the answer; it is the distributive law written out, with 6 decomposed as 2 + 4 because those are the powers of two its bits select.
The immediate practical consequence: multiplying by any power of two involves no addition at all. 10110 × 1000 is 10110 with three zeros glued on, because 1000₂ is 8 and the only set bit sits in position 3. Try it in the calculator and the staircase collapses to a single green row. This is why x * 8 compiles to a shift instruction in every optimising compiler — one cycle instead of several. You can watch the shift on its own in the bitwise calculator, and confirm the place values that make it work with the binary to decimal calculator.
The Carry That Binary Addition Never Produces
Here is where hand calculations actually break, and it catches people who are perfectly comfortable with binary addition. Adding two binary numbers, the worst any column can total is 1 + 1 + 1 = 3 — two digits plus one carry — so the carry out is never more than 1. That bound feels like a law. It isn’t. It is a consequence of having only two operands.
Multiplication stacks as many rows as the multiplier has bits. Take 1111 × 1111 (15 × 15). Four rows, every one of them non-zero:
1111 × 1111 ------ 1111 1111 1111 1111 -------- 11100001
Look at the fourth column from the right — the 2³ place. All four rows contribute a 1 there, so it totals 4. Four does not fit in a binary digit. Write 4 mod 2 = 0, carry ⌊4/2⌋ = 2 — a carry of two, into the next column, which now has its own three 1s to deal with. The answer 11100001₂ = 225 is correct, and anyone who assumed carries max out at 1 has already lost it.
The rule is the same one that governs every positional system, stated properly: the digit you write is the total modulo the base, the carry is the total divided by the base, rounded down. In base 2 that is total mod 2 and total ÷ 2, with no cap on the quotient. The column table in the calculator prints all four rows of that arithmetic — ones counted, carry in, total, digit written — precisely because this is the step worth checking. When you only ever add two numbers the shortcut works, which is why the binary addition calculator can get away with a simpler display.
An 8-Bit Product Doesn’t Fit in 8 Bits
Multiply an m-bit number by an n-bit number and the product needs up to m + n bits. That is not a rule of thumb — it follows directly from the largest values involved. The biggest 4-bit number is 1111₂ = 15, and 15 × 15 = 225, which is 11100001₂: eight bits.
| Operand width | Largest operand | Largest product | Bits needed |
|---|---|---|---|
| 4-bit | 15 | 225 | 8 |
| 8-bit | 255 | 65,025 | 16 |
| 16-bit | 65,535 | 4,294,836,225 | 32 |
| 32-bit | 4,294,967,295 | ≈ 1.8 × 10¹⁹ | 64 |
Addition is far gentler: adding two 8-bit numbers gains at most one bit. Multiplication doubles the width, and that gap is why real processors treat the two operations differently. The x86 MUL instruction writes its result across two registers — DX:AX for a 16-bit multiply — because one was never going to be enough.
In a high-level language nothing warns you. Multiply two 8-bit values in C and the product is computed in int width, then truncated on the way back into a uint8_t: 200 × 3 = 600, but 600 mod 256 = 88, and 88 is what you get. No exception, no flag you are likely to check. Set the register width to 8-bit in the calculator and enter operands whose product exceeds 255 to see exactly which bits fall off the top. Signed types make it worse, since the surviving bit pattern gets reinterpreted under two’s complement — the two’s complement calculator shows how a truncated pattern turns negative.
What a Binary Multiplication Calculator Counts: the 1s, Not the Bits
A shift-and-add multiplier does one addition per set bit in the multiplier, minus one for the first row. Not per bit — per set bit. The consequence is that operands of identical size can cost wildly different amounts of work.
| Multiplier | Decimal | 1s | Additions |
|---|---|---|---|
| 10000000 | 128 | 1 | 0 — pure shift |
| 10000001 | 129 | 2 | 1 |
| 10101010 | 170 | 4 | 3 |
| 11111111 | 255 | 8 | 7 |
Multiplying by 128 is free; multiplying by 255 costs seven additions. And that last row hints at the trick every optimising compiler knows: 255 = 256 − 1, so x * 255 becomes (x << 8) - x — one shift and one subtraction instead of seven additions. Booth’s algorithm generalises exactly this, recognising runs of 1s and replacing them with a subtract-at-the-bottom, add-at-the-top pair. It is the reason multiplier hardware does not slow down on operands full of 1s. Modern CPUs go further still with Wallace and Dadda trees, which sum every partial product in parallel rather than one row at a time; Wikipedia’s binary multiplier article covers those designs in depth.
Five Ways a Hand Calculation Goes Wrong
- Assuming a carry can only be 1. True for addition, false here. Four rows contributing to one column produce a carry of 2. Compute the digit as total mod 2 and the carry as total ÷ 2 every single time, and the problem disappears.
- Skipping the zero rows. Leaving out a 0 bit’s row silently misaligns everything beneath it, and the result is usually off by a factor of two — big enough to be wrong, close enough to look plausible.
- Shifting right instead of left. A left shift multiplies; a right shift divides. Get it backwards on 1011 × 110 and you produce 1 rather than 66.
- Reusing a decimal shortcut. “Multiplying by 10 adds a zero” is about base 10. In binary, appending a zero multiplies by 2. Multiplying by ten (1010₂) needs two rows and an addition.
- Sizing the answer to the register. Two 8-bit operands can need 16 bits. Write the full-width product first, and only then decide what your storage does to it.
One habit catches all five: convert both operands to decimal, multiply there, convert the answer back, and check it matches. The decimal to binary calculator handles the return trip in a second, and the calculator above prints the decimal cross-check under every result for the same reason. Two independent routes to the same number is the cheapest verification there is — and if you want the base-10 arithmetic worked out in its own right, the multiplication calculator does that side.
