Decode Negative Binary

Standard hardware representation. MSB is the sign bit. For positive numbers: read as unsigned. For negative: invert all bits, add 1, then prepend minus. Example: 11111011 (8-bit) → invert = 00000100, +1 = 00000101 = 5, negate = -5. Why this matters: addition just works without a sign-check (3 + (-3) = 0 follows naturally with the carry discarded). C, Rust, Go, and basically all modern CPUs use this for signed integer math.

MSB is sign (1 = negative, 0 = positive). The remaining bits are the magnitude as unsigned. 10000101 (8-bit) → sign=1, magnitude bits=0000101 = 5, decimal = -5. Simpler conceptually than two’s complement but has a quirk: two zero representations: 00000000 = +0 and 10000000 = -0. Also: addition needs to check sign bits and branch. Used in IEEE 754 floating point (sign bit + exponent + mantissa) and in some old machine architectures (like PDP-1).

MSB is sign. Negative values are bitwise NOT of the positive value. 11111010 (8-bit) → invert = 00000101 = 5, negate = -5. No “+1” step (that’s what makes it different from two’s complement). Also has two zero representations (00000000 = +0, 11111111 = -0). Used historically (UNIVAC 1100, CDC 6600) and still appears in IP checksum calculations (one’s-complement-of-the-one’s-complement-sum). Tail end of old-CPU representations.

Mathematical curiosity, not used in real hardware. Same digits as binary (0 and 1) but the place values alternate signs: rightmost is 1, then -2, +4, -8, +16, -32, … So 1101 = 1 + 4 + -8 = -3. 110 = -2 + 4 = 2. 10100 = 16 + 4 = 20. Cool feature: no separate sign bit needed – negative numbers arise naturally from the alternating signs. Studied by Donald Knuth (TAOCP vol. 2); occasionally appears in academic computer architecture papers and competitive programming puzzles.

Because 00000000 (sign=0, magnitude=0) = +0 AND 10000000 (sign=1, magnitude=0) = -0. Mathematically the same value but distinct bit patterns. Same problem in one’s complement (00000000 = +0, 11111111 = -0). Two’s complement avoids this: only one zero (00000000), and the extra bit pattern gets allocated to the most-negative value (e.g., 8-bit two’s complement range is -128 to 127, NOT -127 to 127).

For two’s complement and one’s complement, the MSB IS the sign – so width determines which bit is “the sign”. 1111 in 4-bit two’s complement = -1, but in 8-bit (after left-padding to 00001111) = 15. Without an explicit width, the tool auto-detects from input length. If your binary string is missing leading zeros that should be there, the auto-detection misinterprets – that’s when you override to 8/16/32.

Two’s complement: -2^(N-1) to 2^(N-1)-1. So 8-bit: -128 to 127; 16-bit: -32,768 to 32,767. Sign-magnitude: -(2^(N-1)-1) to 2^(N-1)-1. 8-bit: -127 to 127 (note: only 256 distinct values, one of which is -0). One’s complement: same range as sign-magnitude, also with negative zero. Negabinary: depends on bit count, with an asymmetric range like 4-bit -10 to 5. For practical work, stick with two’s complement.

Split on newlines, commas, or semicolons. Each value validated independently – invalid ones get an inline error marker like # Line 3 "abc": ERROR - Contains non-binary characters while valid ones decode normally. Stats card shows total decoded vs total errors. With “Show decoding steps” enabled, each result is a multi-line walkthrough; otherwise one-line per input.

Yes. All decoding happens in your browser using native BigInt arithmetic. Binary strings (no matter how long) never leave your device. Output download generated and offered locally.