A half adder and a full adder solve almost the same problem — add two bits together — but only one of them can actually be chained into a multi-bit adder. The difference is one extra input, and it changes more about the circuit than it might seem to at first glance.
The half adder: 2 inputs
Adds exactly two bits, A and B, with no way to account for a carry from a previous stage:
| A | B | Sum | Carry |
|---|---|---|---|
| 0 | 0 | 0 | 0 |
| 0 | 1 | 1 | 0 |
| 1 | 0 | 1 | 0 |
| 1 | 1 | 0 | 1 |
Simple, and correct — for exactly one bit position with nothing to add in from a neighboring stage.
The full adder: 3 inputs
Adds A, B, and a carry-in (Cin) from a previous stage — covered in full, with both outputs verified, in the full adder worked example:
What actually changes
It's not just "one more input" in a minor sense — it changes the entire structure of both outputs. The half adder's Sum is a simple 2-input XOR; the full adder's Sum is a 3-input XOR, structurally identical to the parity function covered in the parity checker example, and just as resistant to K-map simplification. The half adder's Carry is a single AND gate; the full adder's Cout is the 3-input majority function, requiring three 2-literal terms instead of one.
Why full adders are what actually gets used
A half adder has no way to receive a carry from a previous bit position, which makes it useless for anything wider than a single bit. Real multi-bit addition — 4-bit, 8-bit, 32-bit, whatever the width — is built by chaining full adders, each stage's Cout feeding directly into the next stage's Cin. The only place a half adder actually shows up in practice is the very first (least significant) bit position, where there's no previous carry to receive in the first place — everywhere else, it has to be a full adder.
Try both outputs directly: 2-variable solver for the half adder, or the full adder example pre-loaded with the 3-input case.