Convert Binary to Hexadecimal
11111111 in binary is ff in hexadecimal, so converting binary to hexadecimal changes the digits and nothing else: both are the same quantity, 255.
In decimal
- In binary The value as entered.
- 11111111
- In octal
- 377
- In decimal
- 255
- In hexadecimal
- ff
- Grouped Binary in nibbles of four and hex in bytes of two, which is how both are actually read. Each hex digit is exactly four binary digits, so the two groupings line up. That correspondence is the whole reason hexadecimal exists.
- 1111 1111 | ff
- Fits in Unsigned. A value needing more than 53 bits cannot be held exactly in a JavaScript number, which is why this converter works in BigInt. A float-based converter is silently wrong in the last digits above that.
- 8 bits
- As a character Read as a Unicode code point. This is the 'binary to text' conversion, one character at a time: 65 is A, 97 is a, and the 32 between them is why setting the sixth bit changes case in ASCII.
- U+00FF ΓΏ
How the Number Base Converter works
11111111 in binary is ff in hexadecimal. Both spellings describe the same quantity, 255, and the conversion changes nothing except how it is written.
Every base works the same way: a digit's worth is the base times the worth of the digit to its right. In binary each position is 2 times the last, so 11111111 reads as 1x2^7 + 1x2^6 + 1x2^5 + 1x2^4 + 1x2^3 + 1x2^2 + 1x2^1 + 1x2^0, which comes to 255.
The only conversion here that needs no arithmetic at all. Sixteen is two to the fourth, so each group of four bits maps to exactly one hex digit and nothing carries between groups: split from the right, translate each nibble, done. 1111 is F, 1010 is A, 0000 is 0. This positional correspondence is why hexadecimal was adopted over, say, decimal for machine values: converting binary to decimal requires real division, and converting it to hex requires only a lookup.
Grouped for reading, that is 1111 1111 in binary and ff in hex. Binary is read in nibbles of four because each nibble is exactly one hex digit; hex is read in pairs because each pair is one byte.
One limit worth knowing about converters generally. A value above 2^53 cannot be held exactly in a floating-point number, and most online converters are built on them, so a 64-bit hash or identifier comes back with its last digits silently wrong. This converter uses arbitrary-precision integers, so the conversion is exact at any size.
Number Base Converter FAQ
What is 11111111 in hexadecimal?
ff. In decimal that is 255, and in the other two bases ff and 377.
How do I convert binary to hexadecimal by hand?
The only conversion here that needs no arithmetic at all. Sixteen is two to the fourth, so each group of four bits maps to exactly one hex digit and nothing carries between groups: split from the right, translate each nibble, done. 1111 is F, 1010 is A, 0000 is 0. This positional correspondence is why hexadecimal was adopted over, say, decimal for machine values: converting binary to decimal requires real division, and converting it to hex requires only a lookup.
Why does this matter outside programming?
Because the two bases are related by a power of two, this particular conversion is the one that happens constantly inside tooling. Debuggers, hex editors and network captures all show the same bytes in both forms, and reading between them is a lookup rather than arithmetic.
Will this be exact for very large numbers?
Yes. The arithmetic here is arbitrary-precision, so there is no point at which digits start being approximated. Converters built on ordinary floating-point numbers lose exactness above 2^53, which 64-bit identifiers routinely exceed.