Hex Converter
Convert between hex, decimal, and binary instantly
Pick the source and target base above, then type a value to convert.
Working…
0.0
It hasn't frozen — the result will appear when the calculation finishes.
About Hex Converter
Type a value in hexadecimal, decimal, or binary and the tool shows the other two. It uses JavaScript's BigInt under the hood, so there is no length limit: a 64-bit hash or a 128-bit UUID written as one number converts without its last digits being rounded away.
With the default bit width (Unlimited) values are unsigned, so FF means 255. Yet in a debugger or a hex dump, FF very often means -1. Pick a bit width of 8, 16, 32 or 64 and turn on Signed (two's complement), and FF reads as -1 and the decimal field accepts negative numbers such as -5. The sections below explain why the same bit pattern can be both. Fractions are not accepted in any mode.
Why 0xFF can be -1: two's complement
Memory does not store a sign separately. An 8-bit cell simply holds 11111111; read it as an unsigned byte (uint8) and you get 255, read it as a signed byte (int8) and you get -1. Practically every modern CPU represents signed integers in two's complement, and the rule is short: in an n-bit value, if the top bit is 1, the real value is the unsigned value minus 2^n.
For 8 bits, 0xFF = 255 - 256 = -1, 0x80 = 128 - 256 = -128, and 0x7F = 127. That is why int8 runs from -128 to 127, one step longer on the negative side. Going the other way, to write -5 as an 8-bit hex value, set the width to 8, turn on signed mode and enter -5 in decimal (in unsigned mode, entering 256 - 5 = 251 gives the same): you get FB, or 11111011 in binary.
Two's complement won because one adder circuit handles both addition and subtraction. Add 00000001 to 11111111 (-1) and you get 1_00000000; the carry falls off the end of the 8-bit cell and what remains is 0. Sign-magnitude and ones' complement schemes both end up with a +0 and a -0; two's complement has exactly one zero.
You cannot read a sign without the bit width
Whether FF is -1 depends entirely on how wide the container was. In a 16-bit field, 0x00FF is just 255, and -1 is 0xFFFF. In 32 bits it is 0xFFFFFFFF; in 64 bits, sixteen F's. What matters is not how many F's you see but whether the top bit of the full width is set.
With the width set to Unlimited the tool strips leading zeros, so entering 0x00FF returns FF. Pick a width and the output is zero-padded to it (FF becomes 00FF at 16 bits), and values that do not fit are flagged as out of range.
- 8-bit (byte): 00 to FF; signed range -128 to 127
- 16-bit (short): 0000 to FFFF; signed range -32,768 to 32,767
- 32-bit (int): largest signed value 0x7FFFFFFF = 2,147,483,647
- 64-bit (long): largest signed value 0x7FFFFFFFFFFFFFFF = 9,223,372,036,854,775,807
Why programmers write hex at all
Since 16 = 2^4, one hex digit maps to exactly four binary digits (a nibble). A byte is always two hex digits, and you can convert in your head by splitting binary into groups of four. Decimal has no such alignment: the jump from 255 to 256 changes the digit count for reasons unrelated to bit boundaries. That is why color codes (#RRGGBB), MAC addresses, memory addresses and UTF-8 byte sequences are all written in hex.
The 0x prefix from C-family languages and the 0b prefix for binary are both accepted here. Spaces are ignored, so a byte-spaced value like DE AD BE EF can be pasted as is. Input is case-insensitive; hex output is uppercase.
Common traps when reading hex from other tools
Byte order. A hex dump of a 32-bit integer on an x86 or ARM machine usually shows bytes in little-endian order, so the value 0x12345678 appears in memory as 78 56 34 12. If you paste the dump bytes in that order, you will get 0x78563412 = 2018915346 instead of 305419896. Reverse the bytes first.
Sign extension. When a signed byte like 0xFB (-5) is widened to 32 bits, the CPU copies the top bit into all new positions and you get 0xFFFFFFFB, not 0x000000FB. Seeing a run of leading F's in a register usually means a small negative number was sign-extended.
Worked examples
Reading FB from a hex dump as a signed byte
- Input
Hex FB- Output
Decimal 251, binary 11111011
The top bit is 1, so as int8 it is 251 - 256 = -5. As uint8 it stays 251.
Largest signed 32-bit integer
- Input
Decimal 2147483647- Output
Hex 7FFFFFFF, binary 31 ones
Add one and you get 80000000, which int32 reads as -2,147,483,648. That is integer overflow wrapping to a negative number.
Byte-spaced input
- Input
Hex DE AD BE EF- Output
Decimal 3735928559
Spaces are ignored. 0xDEADBEEF is a long-standing marker for uninitialized or freed memory. As a signed int32 it reads 3735928559 - 4294967296 = -559038737.
How to use it
- Pick the field for the base you have: hex, decimal or binary.
- Enter the value; 0x/0b prefixes and spaces are fine. To read it as a signed integer, pick a bit width and turn on signed mode.
- Read or copy the other two representations.
Frequently asked questions
Can I enter a negative number?
Yes, once you pick a bit width (8, 16, 32 or 64) and turn on Signed (two's complement). At 16 bits, -1 gives FFFF; a value that does not fit, such as -129 at 8 bits, is flagged as out of range. 64-bit values are exact because the math uses BigInt.
Is it exact for very large numbers?
Yes. BigInt arithmetic has no digit limit. Ordinary JavaScript numbers lose precision above 2^53, but that does not apply here.
Does it convert fractions like 0.5?
No. Floating-point values are stored in IEEE 754 format, whose bit pattern is not a simple base conversion of the number.
Why did my leading zeros disappear?
With the width set to Unlimited, the output shows the value, not a fixed-width field. Pick a bit width and the hex and binary output are zero-padded to it.
Sources
Last reviewed: