How do you convert binary to hex?
Group the binary digits into blocks of four, starting from the right, and swap each block for a single hexadecimal digit. Four bits (a nibble) have 16 possible patterns, and hex has exactly 16 digits, 0 to 9 then a to f, so every nibble maps to one digit with no arithmetic. 1111 is f, 1010 is a.
That one-to-one mapping is the whole reason hex exists in computing. It's a shorthand for binary that a human can read, and a byte is always exactly two hex digits.
Step by step with the tool
- Paste your bit string, for example
1011010111. Only 0s and 1s, no spaces. - Click Convert.
- Copy the result, here
2d7.
The tool parses the whole bit string as one number and prints it in base 16. That gives the same answer as nibble grouping, which is what you'd do on paper.
The nibble table
Learn these sixteen rows and you can convert binary to hex at reading speed:
| Nibble | Hex | Nibble | Hex |
|---|---|---|---|
| 0000 | 0 | 1000 | 8 |
| 0001 | 1 | 1001 | 9 |
| 0010 | 2 | 1010 | a |
| 0011 | 3 | 1011 | b |
| 0100 | 4 | 1100 | c |
| 0101 | 5 | 1101 | d |
| 0110 | 6 | 1110 | e |
| 0111 | 7 | 1111 | f |
A handy anchor: the left column is just 0 to 7, and the right column is the same patterns with the top bit set, so 8 plus the left value.
Worked example: why you group from the right
Take 1011010111, ten bits. Ten isn't a multiple of four, so one group will be short. Groups must be counted from the right-hand end, because that's where the ones place is:
| Split | Groups | Hex |
|---|---|---|
| From the right (correct) | 10 1101 0111 |
2d7 |
| From the left (wrong) | 1011 0101 11 |
would read as b53, which is a different number |
Pad the short leftmost group with zeros (0010) and it reads as 2. The tool agrees: 2d7. Grouping from the left is the classic mistake, and it only shows up when the bit count isn't a multiple of four, which is exactly when you're least careful.
A 32-bit example
11011110101011011011111011101111 is 32 bits, so eight clean nibbles:
1101 1110 1010 1101 1011 1110 1110 1111 → d e a d b e e f → deadbeef
Thirty-two characters shrink to eight. That compression is why debuggers, packet captures and hash outputs are shown in hex rather than raw bits. RFC 4648 even standardises hex as "Base16" encoding for exactly this job of writing bytes as text.
What the output looks like
- Lowercase, no prefix. You get
deadbeef, not0xDEADBEEF. Add0xyourself for C, JavaScript or Python source code. - No padding.
00001111returnsf. If you're writing a byte, make it0f. - No grouping. A long result comes out as one run of digits. Split it into pairs if you're reading bytes.
Errors you might see
| You typed | Message | Fix |
|---|---|---|
0b1101 |
Enter a valid binary number... | Drop the 0b |
1010 1011 |
Same | Remove the spaces |
1012 |
Same | Only 0 and 1 are binary digits |
| 54 or more bits | That number is too large to convert precisely. | Convert in chunks, each a multiple of 4 bits long |
The 53-bit ceiling comes from JavaScript numbers being 64-bit floats, which hold integers exactly only up to 2^53 - 1 (MDN). Because hex digits line up with 4-bit boundaries, chunking a long string and joining the hex results gives the correct answer, provided you split from the right in multiples of four bits and pad each later chunk's hex result back to full width (a 48-bit chunk must give 12 hex digits, so restore any zeros the tool dropped).
Related tools
- Hex to binary expands each hex digit back into its four bits.
- Binary to octal uses 3-bit groups instead, handy for Unix permissions.
- Hex to decimal turns the hex result into an ordinary number.
- The random binary generator gives you practice strings to check your nibble reading.
Last updated