Convert decimal and binary values, check signed integer ranges, and follow each step of the two's complement process for homework, coding, and debugging.
Enter a number to see the conversion
This tool is built for the most common tasks you face with signed binary representation: converting a decimal value to a fixed-width binary pattern, reading a stored pattern back into decimal, and checking whether a value fits the bit width you selected.
Choose 8-bit, 16-bit, 32-bit, 64-bit, or a custom width. Bit width sets the valid signed integer range and controls overflow.
Use decimal input when you already know the signed value, or use binary input when you need to decode a stored bit pattern.
Signed mode uses two's complement. Unsigned mode reads the same binary representation as a non-negative integer only.
The results panel shows the binary representation, one's complement, decimal value, and a step-by-step walkthrough so you can verify the math manually.
Start by choosing the bit width before you type the number. If you enter -42 in signed 8-bit mode, the calculator knows the valid range is -128 to 127. If you switch to 4-bit mode, that same number is no longer valid because the range becomes -8 to 7. This matters in real code because a signed integer only keeps the number of bits the data type allows.
Type only 0 and 1, and make sure the bit width matches the pattern you want to decode. For example, 11111011 means -5 in signed 8-bit mode, but it means 251 in unsigned 8-bit mode. The bit pattern is the same. The interpretation changes.
A good online two's complement calculator with steps should do more than return a single binary string. It should help you understand what the bits mean so you can catch mistakes in classwork, coding, and debugging.
This is the signed integer or unsigned integer value that the current binary representation means in the mode you selected. If the most significant bit is 1 in signed mode, the stored value is negative. If you switch to unsigned mode, the same bit pattern becomes a larger positive number instead.
The binary representation is padded to the full bit width. That padding is not decoration. It is part of the stored value. 10110 and 00010110 do not mean the same thing in every context because bit width changes the sign bit, range, and overflow behavior.
The one's complement flips every bit. It is useful as an intermediate step because two's complement is simply one's complement plus 1. Seeing both values side by side makes it easier to understand how negative binary numbers are created.
For any n-bit signed value, the range is -2^(n-1) to 2^(n-1)-1. That is why 8-bit holds -128 to 127 and 16-bit holds -32,768 to 32,767.
The most significant bit is the sign bit in signed mode. A leading 0 means the number is zero or positive. A leading 1 means the stored value is negative.
Languages such as C, C++, Java, Rust, and many embedded systems treat fixed-width signed values with two's complement rules. That affects overflow detection, bit masks, arithmetic right shifts, and how raw bytes are decoded.
Suppose you store -42 in 8-bit signed form. First convert 42 to binary: 00101010. Invert the bits to get 11010101. Add 1 to get 11010110. That final pattern also equals 0xD6 in hexadecimal output, which is why hex dumps often show negative values that do not look negative at first glance.
If you only need a fast sign check, look at the leftmost bit. If it is 1 in signed mode, the stored value is negative. Then use the calculator steps to confirm the exact decimal result.
If you want to know how to calculate two's complement manually, you only need two core rules: flip the bits, then add 1, or use the equivalent formula 2^n - x for an n-bit negative value.
For -18 in 8-bit, start with 18 = 00010010. Invert it to get 11101101. Add 1 to get 11101110. That is the signed binary representation of -18.
In n-bit two's complement, the stored pattern for a negative value -x can also be found by calculating 2^n - x. This gives the unsigned bit pattern that the computer stores.
For -42 in 8-bit: 2^8 - 42 = 256 - 42 = 214. Convert 214 to binary and you get 11010110, which matches the flip-and-add-1 method. Both methods are correct. The first is easier to visualize. The second is useful in digital logic, assembly, and low-level debugging.
When you already have a binary representation, first inspect the most significant bit. If it is 0, the value is positive and you can read it as ordinary binary. If it is 1, invert the bits, add 1, then apply the negative sign.
Example: 11101011 in signed 8-bit mode. The leading bit is 1, so the value is negative. Invert to get 00010100. Add 1 to get 00010101, which equals 21 in decimal. The original stored value is therefore -21. This reverse process is one of the most common tasks in computer architecture classes and while reading memory, packet, or sensor data.
Two's complement shows up anywhere a fixed-width signed integer is stored. These examples mirror the kinds of real values you see in programming assignments, embedded systems, and byte-level debugging.
A temperature sensor sends 11110110. In signed 8-bit mode, that is -10. If your code reads the same byte as unsigned, it becomes 246 and your output looks broken. Always match the device specification to the correct signed integer type.
Add 100 and 60 in signed 8-bit math. The true decimal answer is 160, but 8-bit signed integers only go up to 127. The stored result wraps to 10100000, which is -96. If you do not check overflow detection, the sign looks wrong even though the CPU followed the binary arithmetic rules exactly.
A debugger shows 0xFF9C in a 16-bit signed field. In binary that is 1111111110011100. Decode it as two's complement and you get -100. This is common when you inspect network packets, firmware logs, or machine code output where values are grouped as hexadecimal output.
Suppose a motor controller stores speed in signed 12-bit form. The valid range is -2048 to 2047. If you try to store -2500, the value does not fit and your program must reject or clamp it before the hardware uses the wrong binary representation.
The bit pattern 10000001 equals -127 in signed 8-bit mode, but it equals 129 in unsigned mode. If you mix the two in one program, a simple comparison or cast can change the result you see on screen.
Many students learn that ~x + 1 is the same as -x. Try x = 5 in 8-bit: 00000101. Bitwise NOT gives 11111010. Add 1 and you get 11111011, which is -5. This identity is useful when you work with binary arithmetic and ALU design.
This is the biggest content gap on the original page and one of the main reasons competing pages rank well. Searchers do not just want a converter. They want help understanding why values break when the bit width changes.
Notice there is always one more negative value than positive value. That happens because zero uses one of the non-negative patterns. It is also why the minimum negative value is a special edge case.
Overflow happens when the true math answer is outside the allowed range of the selected bit width. In 8-bit signed math, 127 + 1 becomes 10000000, which the system reads as -128. The bits are valid. The mathematical meaning changed because the value wrapped.
A quick overflow rule for addition is simple: if you add two positive values and get a negative result, or add two negative values and get a positive result, signed overflow occurred.
Sign extension keeps a signed value the same when you move it to a larger bit width. You copy the most significant bit into the new left-side positions.
Example: -42 in 8-bit is 11010110. In 16-bit, it becomes 1111111111010110. Because the sign bit is 1, the added bits are also 1. If you padded with zeros instead, you would silently change the number to a positive value.
One's complement flips bits but does not add 1. It creates a positive zero and a negative zero, which makes arithmetic harder. Two's complement fixes that with a single zero value.
Unsigned binary uses every bit for magnitude, so an 8-bit unsigned value runs from 0 to 255. Signed 8-bit two's complement uses the leftmost bit for sign, so the range becomes -128 to 127. That tradeoff is why the same byte can mean very different numbers in different programs.
If you work with binary representation often, these LiteCalc tools can help you move between number systems and verify the next step in your workflow.
Use this tool when you need descriptive precision rules for lab work, engineering homework, and measured values.
Helpful when you need a descriptive trigonometry calculator for right triangles, angles, and coordinate math.
Great for number structure, divisibility checks, and prime factorization when you move between decimal math tasks.
Useful for coordinate geometry problems where you need a clear slope formula and worked line examples.
A practical next step when your math work shifts from binary logic to sides, angles, area, and perimeter.
Helpful for square root, cube root, and nth-root problems that often appear beside binary and number-system practice.
Get answers to common questions about two's complement, signed binary values, and overflow.
Two's complement is the standard way computers store signed integers in binary. Positive values use normal binary with a leading 0, while negative values are encoded by flipping the positive bits and adding 1. This method gives you one zero value, simple binary arithmetic, and consistent signed integer behavior across modern CPUs.
Write the positive binary value in the chosen bit width, invert every bit, and add 1. For example, to find the 8-bit two's complement of 5, start with 00000101, invert to 11111010, then add 1 to get 11111011. That final pattern represents -5.
Choose the bit width first, convert the absolute value to binary, pad it with leading zeros, invert every bit, and add 1. For example, -42 in 8-bit starts with 00101010, becomes 11010101 after inversion, and ends as 11010110 after adding 1.
If the most significant bit is 0, read the number as normal binary. If it is 1, invert the bits, add 1, convert that result to decimal, and place a negative sign in front. For example, 11111011 becomes 00000100 after inversion, then 00000101 after adding 1, so the signed decimal value is -5.
An 8-bit signed two's complement value ranges from -128 to 127. More generally, an n-bit signed value ranges from -2^(n-1) to 2^(n-1)-1. This is why 16-bit signed integers go from -32,768 to 32,767.
The largest positive 8-bit signed value is 01111111, which equals 127. Add 1 and the result becomes 10000000. In two's complement, that stored pattern represents -128, so the value wraps because signed overflow happened.
Sign extension means copying the sign bit into the new left-side bits when you move a signed value into a wider data type. For example, 11010110 is -42 in 8-bit form. In 16-bit form it becomes 1111111111010110, not 0000000011010110, because the sign bit must be preserved.
One's complement flips each bit and stops there. Two's complement flips each bit and then adds 1. That extra step is why two's complement has only one zero value and why binary arithmetic works cleanly in modern hardware.
Use signed binary when the value can go below zero, such as temperatures, velocity, balance changes, or arithmetic results. Use unsigned binary when values are always zero or greater, such as file sizes, counters, memory offsets, or bit masks. The same binary pattern can mean different numbers depending on which mode you choose.