Signed and Unsigned Integer Converter

Interactive Calculator

Enter a value — every result updates instantly, in your browser. Free forever, no sign-up.

Signed vs unsigned integers: the one-bit difference that changes everything

A fixed-width integer is just a pattern of n bits; signedness decides how to read the most significant bit. Unsigned integers use all n bits for magnitude, so an 8-bit unsigned value runs from 0 to 255. Signed integers reserve the top bit as a sign flag and use two’s complement, so an 8-bit signed value runs from −128 to 127. Both types occupy the same byte in memory; only the interpretation changes. That is why a hex dump cannot tell you whether 0xFF means 255 or −1 until you know the declared type. The split is not symmetrical: zero consumes one non-negative pattern, leaving 128 negative patterns but only 127 positive ones at 8 bits. When you debug a conversion, write the width and signedness together — for example uint8_t or int16_t — before looking at the decimal value.

Two’s complement: why −1 is all ones

Two’s complement represents a negative value by inverting the bits of its magnitude and adding one, discarding any carry beyond the fixed width. At 8 bits, −5 starts as 00000101, inverts to 11111010, and becomes 11111011. The same rule makes −1 the all-ones pattern: 00000001 → 11111110 → 11111111. This design has three practical advantages over sign-magnitude and one’s complement: there is only one zero, addition and subtraction use the same hardware, and the sign bit falls out of ordinary binary arithmetic. It also explains the asymmetric range: 10000000 is −128, but there is no positive 128 in an 8-bit signed type. When you see 0xFFFFFFFF in a 32-bit signed context, the CPU is not storing a special minus sign; it is storing the bit pattern that two’s complement defines as −1.

Sign extension vs zero extension

Widening an integer is not just padding with zeros. A signed value must be sign-extended: the new high bits copy the old sign bit. An unsigned value is zero-extended: the new high bits become 0. At 8 bits, the pattern 0xFF is −1 as int8_t and 255 as uint8_t. Widening int8_t −1 to 16 bits gives 0xFFFF (−1), while widening uint8_t 255 gives 0x00FF (255). C and C++ integer promotion rules apply this automatically, but casts and protocol fields can silently change the rule. The classic bug is reading a signed byte from a buffer into a wider unsigned type without masking: the compiler sign-extends first, and 0xFF becomes 0xFFFFFFFF instead of 0x000000FF. Always mask with 0xFF before widening raw bytes when you intend an unsigned value, and use fixed-width types such as int16_t and uint16_t to make the rule explicit.

Integer overflow, wraparound and undefined behavior

Overflow behavior is a language contract, not a hardware guarantee. Unsigned arithmetic in C and C++ wraps modulo 2^n and is well defined: UINT32_MAX + 1 becomes 0. Signed overflow in C and C++ is undefined behavior, which means the compiler may optimize as if it never happens; do not rely on a friendly wraparound. Java defines int and long wraparound, C# distinguishes checked and unchecked contexts, Rust panics in debug builds and wraps in release builds, Go wraps two’s complement, and Python integers grow without a fixed width. JavaScript Number is exact only to 2^53 − 1, so 64-bit work needs BigInt. Before adding or multiplying, check the boundary: for signed values, compare against INT32_MAX or use a wider type; for unsigned values, check whether the result is less than either operand. The formula (a + b) mod 2^n describes the bits, but it does not make signed overflow legal in C or C++.

Bit width, ranges and the language types you actually meet

The width determines every boundary. int8_t and uint8_t cover −128 to 127 and 0 to 255; int16_t and uint16_t cover −32,768 to 32,767 and 0 to 65,535; int32_t and uint32_t cover −2,147,483,648 to 2,147,483,647 and 0 to 4,294,967,295; int64_t and uint64_t cover −9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 and 0 to 18,446,744,073,709,551,615. C’s plain int is only guaranteed to be at least 16 bits, so use <stdint.h> types when the width matters. Java byte is signed, Java has no unsigned int, and C# byte is unsigned. Python integers are arbitrary precision, while JavaScript Number is a double. The name of a type is not a guarantee across languages or compilers — check the actual width, then check the signedness, then check the range.

Endianness is not signedness

Signedness and endianness answer different questions. Signedness decides whether the most significant bit is a sign; endianness decides the order in which bytes are stored in memory or sent over a wire. A 32-bit value 0x12345678 is stored as 12 34 56 78 in big-endian and 78 56 34 12 in little-endian, but its signed interpretation is identical once the four bytes are assembled correctly. Network protocols traditionally use big-endian byte order, often called network byte order, while x86 and many ARM systems are little-endian in memory. To read a signed field, first collect the bytes in the declared order, assemble them into an unsigned value, then apply the sign bit. Reversing the bytes and applying two’s complement are separate steps; doing only one of them is a common source of wildly wrong sensor readings and protocol bugs.

Casts, promotions and the usual arithmetic conversions

C and C++ do not compare unlike types directly. Integer promotion widens types smaller than int to int, then the usual arithmetic conversions choose a common type. If one operand is unsigned and its rank is at least the signed operand’s rank, the signed operand is converted to unsigned. That is why −1 < 0u evaluates to false: −1 becomes UINT_MAX before the comparison. This is not a compiler bug; it is the language rule. Compile with -Wsign-compare and treat warnings as errors. Java widens byte and short to int with sign extension, so byte b = −1; int i = b; gives −1, while b & 0xFF gives 255. C# offers checked and unchecked contexts, and Rust requires explicit casts. When a boundary matters, cast both sides to the same fixed-width type, or use a helper such as std::cmp_less in C++20, instead of relying on implicit promotion.

Reading hex dumps and binary protocols without guessing

A hex dump is just bytes; it does not carry type metadata. Before converting a field, write down three facts: width in bytes, signedness, and byte order. A two-byte field FF FF is 65,535 as uint16_t and −1 as int16_t; the same bytes little-endian are still FF FF in this case, but 0x1234 would become 34 12. For each field, mask the bytes into the target width, shift them into place, then apply the sign bit. In C, uint8_t b = 0xFF; int16_t s = (int16_t)(int8_t)b; makes the signed interpretation explicit. In Java, (short)(b & 0xFF) keeps 255. Document the layout next to the parser, add boundary tests for 0x00, 0x7F, 0x80 and 0xFF, and compare your result with this calculator before you ship a parser that silently reinterprets every negative sensor reading as a huge positive number.

Bit masks, shifts and unsigned pitfalls

Bit manipulation is safest in unsigned types. Right-shifting a signed negative value is implementation-defined in C and C++ (most compilers perform an arithmetic shift, filling with 1s), while unsigned right shift always fills with zeros. Left-shifting a negative signed value, or shifting a signed 1 into the sign bit, is undefined behavior; use 1u << 31 or uint32_t{1} << 31 instead of 1 << 31. Masks isolate fields: value & 0xFF keeps the low byte, and (value >> 8) & 0xFF reads the next byte. Always mask before widening, because sign extension can contaminate the high bits. Rotations are not shifts: a rotate preserves every bit while a shift discards the bits that fall off the end. When you see a mysterious negative number after a mask, check whether the top bit of the result is set and whether the destination type is signed; the bit pattern may be correct while the interpretation is not.

How to verify a signed/unsigned conversion in five minutes

A repeatable checklist catches almost every conversion bug. First, write the width and signedness: int16_t, uint32_t, and so on. Second, write the allowed range and compare the input before doing any math. Third, convert to hex at the exact width; a 32-bit value should have eight hex digits, including leading zeros. Fourth, check the top bit: 1 means the signed reading is negative, 0 means it is non-negative. Fifth, convert back and compare the raw bit pattern, not just the decimal value. Sixth, test the boundary set: 0, 1, −1, signed max, signed min, 2^(n−1), 2^n − 1, and one past each limit. In code, add static_assert(sizeof(int32_t) == 4) or language equivalents, and keep a small table of expected hex values in your tests. If a value survives the round trip at 8, 16, 32 and 64 bits, your parser is probably honest.

Signedness in APIs, JSON and databases

Signedness problems rarely stay inside one language. JSON numbers are commonly parsed as IEEE-754 doubles, so a 64-bit integer above 2^53 − 1 can lose precision before your code ever sees it; serialize large IDs and counters as strings, or use a parser with a BigInt mode. Databases differ too: MySQL has UNSIGNED integer types, PostgreSQL does not, and SQLite stores integers dynamically. A value that is 4,294,967,295 in MySQL may not fit a signed INT column elsewhere. In APIs, document the width, signedness and range for every integer field, and validate on the boundary rather than trusting the client. If a field can represent −1 and 4,294,967,295, it is ambiguous unless the schema says which one is valid. The safest contract is an explicit type plus a range check, not a bare number in a JSON object.

Frequently Asked Questions (30)

Long-tail answers: each question targets a real Google search about signed and unsigned integer converter — click to expand.