Sign-magnitude notation, the way people actually write negatives
When a person writes -255 on paper, they're using sign-magnitude notation: a sign (plus or minus) attached to an unsigned magnitude. It's intuitive precisely because it mirrors how negation works in ordinary arithmetic — flip the sign, keep the number the same. This tool applies that same convention to hex: -255 becomes -0xFF, a minus sign followed by the hex magnitude of 255. That's distinct from — and simpler than — how a computer actually stores a negative integer in memory, which uses two's complement rather than a separate sign symbol.
Why computers don't use sign-magnitude internally
Sign-magnitude seems like the obvious choice for hardware too, but it has two practical problems that two's complement avoids. First, it wastes a bit pattern: with a dedicated sign bit, both+0 and -0 are representable as distinct patterns, even though mathematically there's only one zero — that's one fewer usable value than a scheme that doesn't need a separate negative zero. Second, and more importantly for hardware design, adding a negative sign-magnitude number to a positive one isn't the same operation as ordinary addition — a CPU would need extra logic to detect sign and either add or subtract magnitudes accordingly. Two's complement sidesteps both problems: it has exactly one representation of zero, and ordinary binary addition on two's complement values just works, whether the operands are positive or negative, without any special-casing.
When sign-magnitude is still the right notation
Despite computers not using it internally, sign-magnitude is exactly right for representing a signed quantity meant for a person to read — a temperature reading, a financial gain or loss, a coordinate offset, or any value where "the number is 255, and it's negative" is a more natural framing than a fixed-width bit pattern. Converting a negative decimal number to sign-magnitude hex is useful when preparing human-readable output, logging, or documentation, where a reader expects to see a minus sign rather than decode a two's complement pattern in their head. It's the right tool when the audience is a person, and the wrong one when the audience is a fixed-width register, memory layout, or wire protocol that has already committed to two's complement.
Converting between the two conventions
Going from sign-magnitude to two's complement (or the reverse) requires knowing the target bit width, because two's complement is inherently a fixed-width representation — sign-magnitude notation, in contrast, doesn't need one, since the magnitude can be written with as many or as few hex digits as needed. -1 in sign-magnitude is simply -0x1, one hex digit, regardless of context. In two's complement, -1 is 0xFF at 8 bits, 0xFFFF at 16 bits, or0xFFFFFFFF at 32 bits — the same value requires a different bit pattern depending on width, because two's complement's negative range is defined relative to the total number of bits available. That width-dependence is precisely why this tool and thesigned integer converter are kept separate: one notation needs a declared width to mean anything, and the other doesn't.
A quick worked comparison
Take -16. In sign-magnitude hex, that's simply -0x10 — a minus sign and the hex value of 16, no width required. In two's complement at 8 bits, the same quantity is stored as 0xF0, derived by inverting the bits of positive 16 (0x10, or 00010000) to get11101111, then adding 1 to get 11110000, which is 0xF0. Both represent -16; they simply answer different questions — "what's the sign and magnitude" versus "what's the exact bit pattern a register would hold."
Neither representation is more "real" than the other — they're both accurate descriptions of the same negative quantity, chosen for different audiences. Sign-magnitude is how the number would be spoken or written by hand; two's complement is how it would be found sitting in a CPU register or a file's binary layout. Confusing the two — reading a two's complement byte as if it were sign-magnitude, or vice versa — produces a wrong value without any error or warning, which is worth keeping in mind whenever a hex byte's sign is in question.