Two's Complement Explained: How Computers Store Negative Numbers

The problem: binary has no minus sign

Memory holds bits, so a negative number needs an encoding. The obvious idea, sign and magnitude, uses the top bit as a sign flag and the rest as the value: 00000101 is 5 and 10000101 is −5. It has two flaws. There are two zeros, 00000000 and 10000000, which every comparison has to treat as equal. And adding a positive and a negative number needs different circuitry from adding two positives. Ones' complement, used by some early machines, negates by inverting every bit; it still has a negative zero and needs an "end-around carry" when adding.

Two's complement removes both problems. There is exactly one zero, and the ordinary binary adder that handles unsigned numbers gives the right answer for signed numbers too, with no special cases. That is why every processor in common use, from phones to servers, uses it, and why C++20 and C23 finally made it the only representation the language standards allow.

How it works

Think of an 8-bit number as eight weighted positions. Unsigned, the weights are 128, 64, 32, 16, 8, 4, 2 and 1. Two's complement changes exactly one thing: the top bit is worth −128. So 10000000 is −128, 10000001 is −128 + 1 = −127, and 11111111 is −128 + 127 = −1.

An equivalent way to see it: a negative number −x is stored as 2ⁿ − x. In 8 bits, −5 is stored as 256 − 5 = 251. This is arithmetic modulo 2ⁿ, the same wrap-around you get on a clock face, which is exactly why addition works without special cases: 7 + (−5) is 7 + 251 = 258, and 258 modulo 256 is 2.

Negating: invert and add one

To find the bits of −x, flip every bit of x and add one. Flipping every bit gives 2ⁿ − 1 − x, so adding one gives 2ⁿ − x, which is the definition above.

  5  =  0000 0101
 ~5  =  1111 1010     invert every bit
+1   =  1111 1011     = −5  (0xFB, or 251 read as unsigned)

check: 0000 0101 + 1111 1011 = 1 0000 0000 → the carry falls off the top → 0

The same rule works in reverse, so applying it twice returns the original number. One value has no positive counterpart: the most negative number. In 8 bits, inverting −128 (10000000) and adding one gives 10000000 again. That is why abs(INT_MIN) in C is undefined behavior and returns a negative number in practice, and why Math.abs(Integer.MIN_VALUE) in Java returns −2,147,483,648.

Ranges and sign extension

When a signed value moves into a wider type, it is sign-extended: the top bit is copied into every new bit, so −5 in 8 bits (11111011) becomes 11111111 11111011 in 16 bits, still −5. An unsigned value is zero-extended instead. Mixing the two up is how a byte of 0xFB read from a file turns into −5 when you expected 251, or into 65,531 when you expected −5.

The bugs it causes in real code

• Java's signed bytes. Java has no unsigned byte, so (byte) 200 is −56, and a byte array read from a network socket prints negative values for everything above 127. Mask to recover the unsigned value: b & 0xFF.
• JavaScript bit operators work in 32 bits. Numbers are 64-bit floats, but |, &, ^, ~, << and >> convert their operands to signed 32-bit integers first. So 0xFFFFFFFF | 0 is −1, and 2147483647 + 1 | 0 is −2,147,483,648. The unsigned right shift x >>> 0 reinterprets the result as unsigned, which is why it appears in hashing code. For wider values use BigInt.
• Arithmetic versus logical shift. Shifting a negative number right with >> copies the sign bit in from the left, so −128 >> 1 is −64. A logical shift (>>> in Java and JavaScript) fills with zeros and produces a large positive number instead.
• Silent overflow. In C, signed overflow is undefined behavior, and compilers may optimise on the assumption that it never happens; in Java, C# and Go it wraps. Rust panics in debug builds and wraps in release builds unless you use the checked_, wrapping_ or saturating_ methods. Python's integers never overflow, which hides the problem until the value reaches a database or a C library.
• Counters that hit the limit. YouTube's view counter was a signed 32-bit integer until 2014, when one video approached 2,147,483,647 views and the counter was moved to 64 bits. The same limit is behind the year 2038 problem: signed 32-bit Unix time runs out at 03:14:07 UTC on 19 January 2038.
• Narrowing conversions. In 1996 the first Ariane 5 rocket was lost when software converted a 64-bit floating-point velocity into a 16-bit signed integer, the value was too large to fit, and the resulting exception shut down the guidance system.

Reading signed values from bytes

File formats and network protocols specify both a width and a signedness for every field, plus a byte order. To decode a signed 16-bit big-endian value by hand, combine the bytes as unsigned and then subtract 2¹⁶ if the top bit is set:

// bytes FF 38 → 0xFF38 = 65,336 as unsigned
const u = (bytes[0] << 8) | bytes[1];
const s = u >= 0x8000 ? u - 0x10000 : u;   // −200

// or let the platform do it
new DataView(buffer).getInt16(0, false);   // false = big-endian

Most languages provide the second form: DataView in JavaScript, struct.unpack('>h', …) in Python, ByteBuffer.getShort() in Java, and binary.BigEndian.Uint16 followed by a conversion to int16 in Go. Use them rather than hand-rolled shifts whenever you can.

Frequently asked questions