Two's complement explained

A computer only stores bits, so a negative number needs an encoding. The scheme nearly every processor uses is two's complement, and it explains a handful of things that otherwise look arbitrary: why a signed byte runs from negative 128 to positive 127, why adding one to the largest integer gives the most negative one, and why the same addition circuit works for signed and unsigned numbers.

The rule

To negate a number in two's complement, invert every bit and add one. That is the whole rule. Take 5 in an 8-bit byte:

 5  = 0000 0101
~5  = 1111 1010   (invert every bit)
+1  = 1111 1011   = -5

To read a negative value back, apply the same operation again; inverting and adding one to 1111 1011 returns 0000 0101, which is 5, so the original was negative 5.

The top bit doubles as the sign: if the leftmost bit is 1, the number is negative. But it is not a separate sign flag. It carries real place value, just a negative one. In 8 bits that leftmost bit is worth negative 128, and the rest are the usual positive powers of two:

1111 1011 = -128 + 64 + 32 + 16 + 8 + 2 + 1 = -5

Why addition just works

The reason two's complement won out over older schemes is that ordinary binary addition gives the correct signed result with no special handling. Compute 7 plus negative 5:

  0000 0111   ( 7)
+ 1111 1011   (-5)
= 1 0000 0010

Discard the carry out of the top bit and you have 0000 0010, which is 2. The same adder handles signed and unsigned operands, which is why hardware does not need separate circuits for each.

One extra negative

An 8-bit two's complement byte represents values from negative 128 to positive 127. The range is lopsided: there is one more negative number than positive. This falls out of the encoding. Zero uses up one of the non negative slots (0000 0000), leaving 127 positive values, while the negatives get a full 128. The lone extra is 1000 0000, which is negative 128 and has no positive counterpart. Negating it overflows back to itself, a genuine edge case that has caused real bugs in abs() implementations.

Overflow wraps around

Because the values live on a fixed width wheel, going past the top rolls over to the bottom. Add one to the largest signed byte:

 0111 1111  ( 127)
+0000 0001
=1000 0000  (-128)

127 plus 1 becomes negative 128. The same wraparound is why a counter that overflows suddenly reports a large negative number, and it is the mechanism behind the year 2038 problem, where a 32-bit signed timestamp wraps from 2038 back to 1901.

To see any of this directly, paste a value into the base converter and read its binary form, then flip bits by hand to check the negation. The conversion runs entirely in your browser, so nothing you enter is transmitted. Once invert-and-add-one is muscle memory, signed integer behavior stops being mysterious and overflow becomes something you can predict. For the broader picture, see converting between binary, hex, and decimal.