Two’s complement calculator
−42 in eight bits is 11010110. Hand those eight bits to something expecting an unsigned byte and it reads 214, and both readings are correct — the bits do not record which one was meant. That is the whole reason a type declaration exists, and reading a signed buffer as unsigned is one of the most durable bug shapes in systems code.
Enter a decimal value and a width and this gives the two’s complement bit pattern, its hexadecimal form, and what those same bits read as both signed and unsigned. −42 in eight bits is 11010110, which is D6 in hex and 214 if read as unsigned. The range row shows what the width can hold — −128 to 127 for eight bits — and the fits row says whether your value wrapped.
How to use it
Two’s complement is how essentially every processor built since the 1960s stores a negative integer, and it won for one reason that has nothing to do with elegance: it lets a single adder circuit handle signed and unsigned arithmetic without knowing which it has.
Invert and add one
To negate a value, flip every bit and add one. Take 42 in eight bits: 00101010. Inverted it is 11010101, and adding one gives 11010110, which is −42. Going back is the same operation again, which is the property that makes it work — negation is its own inverse. The arithmetic reason is that at width n the representation of −v is 2ⁿ − v, so the bits of a negative number and the bits of its unsigned counterpart differ by exactly the width’s span. That is why addition needs no special case: adding 11010110 to some other byte and letting the carry fall off the top produces the right answer whether you meant the byte as −42 or as 214.
The range is asymmetric and that is a real bug source
Eight bits hold −128 to 127, not −127 to 127. There is one more negative value than positive, because zero occupies a slot on the positive side and leaves one fewer there. The consequence is sharp: the most negative value has no positive counterpart, so negating −128 in eight bits gives −128 again, and taking its absolute value returns a negative number. This is not a hypothetical. It is a documented edge case in the C standard library, it has produced real vulnerabilities, and it is why careful code checks for the minimum before negating. The same holds at every width: −32768 at sixteen bits and −2147483648 at thirty-two.
Overflow wraps and says nothing
Go past the top of the range and the value wraps around to the bottom rather than raising anything. Adding 1 to 127 in eight bits gives −128. That is what the fits row is for: it tells you the value you typed does not survive at the width you chose, before the wrapped figure misleads you. Whether this is defined behaviour or not depends entirely on your language — some wrap by specification, some treat signed overflow as undefined and let the optimiser assume it cannot happen, which is how an overflow check written after the overflow gets deleted by the compiler.
One’s complement and why it lost
The obvious alternative is to flip the bits and stop, which is one’s complement. It is simpler to describe and worse to build, because it produces two representations of zero — all zeros and all ones — so every comparison needs a special case and the adder needs an end-around carry. Sign-and-magnitude, where one bit just records the sign, has the same twin-zero problem. Two’s complement has exactly one zero and one adder, and that is the entire argument.
What this does not do
It represents integers. Fractions are truncated toward zero on the way in, because two’s complement is an integer encoding; a fractional value in binary is a fixed-point or floating-point question and a different one. For plain unsigned conversion between bases with no sign involved, the number base converter is the simpler tool.
What people use it for
- Checking what a negative value looks like in a fixed-width register
- Working out why a byte read as 214 when you wrote −42
- Confirming whether a value fits in int8, int16 or int32
- Understanding an overflow that wrapped instead of erroring
- Reading a hex dump that contains signed values
- Teaching or checking the invert-and-add-one procedure
Questions
Take the positive value in binary, invert every bit, and add one. 42 is 00101010, inverted is 11010101, plus one is 11010110, which is −42 in eight bits. Doing it a second time takes you back.
−128 to 127. There is one more negative value than positive, and the same pattern holds at every width: −32,768 to 32,767 at sixteen bits, and −2,147,483,648 to 2,147,483,647 at thirty-two.
Because zero takes a slot on the positive side. Half the patterns have the top bit set and are negative, half do not, and one of that second half is zero — leaving one fewer positive value than negative.
Nothing good. −128 in eight bits negates to −128, because 128 has no representation at that width. Taking an absolute value without checking for the minimum first is a genuine, documented source of bugs rather than a curiosity.
The value wraps silently. Adding 1 to 127 in eight bits gives −128, with nothing raised and nothing logged. The fits row here tells you when the value you entered has done that.
Because the bits do not record which interpretation was intended. 11010110 is −42 read as signed and 214 read as unsigned, and only the type declaration in your code decides. Reading a signed buffer as unsigned, or the reverse, is a long-running class of bug.
Because addition and subtraction then work identically for signed and unsigned values, so hardware needs one adder rather than two paths. Sign-and-magnitude and one’s complement both give you two representations of zero and a special case in every comparison.
No. Two’s complement encodes integers, so a fractional input is truncated toward zero. Fractional binary is fixed point or floating point, which is a separate representation with separate rules.