Binary to hex
| Decimal | Binary | Octal | Hex |
|---|---|---|---|
| 0 | 0 | 0 | 0 |
| 1 | 1 | 1 | 1 |
| 8 | 1000 | 10 | 8 |
| 10 | 1010 | 12 | A |
| 15 | 1111 | 17 | F |
| 16 | 10000 | 20 | 10 |
| 64 | 1000000 | 100 | 40 |
| 100 | 1100100 | 144 | 64 |
| 255 | 11111111 | 377 | FF |
| 256 | 100000000 | 400 | 100 |
| 1024 | 10000000000 | 2000 | 400 |
| 65535 | 1111111111111111 | 177777 | FFFF |
Group the binary digits into fours starting from the right, padding the left with zeros, then read each group as one hex digit. 10101111 becomes 1010 1111, which is AF.
How to convert binary to hex
Padding direction is the mistake worth avoiding. Binary places carry value by position from the right, so a group of fewer than four bits must be padded on the left with zeros. The grouped output above always pads correctly, which is why it is worth reading rather than doing it by eye on a long string.
Six bits make the point concretely. 110110 padded on the left is 0011 0110, which reads as 36 in hex and 54 in decimal. Padded on the right it would be 1101 1000 — D8, or 216 — four times too large, because every bit has been shoved two places up. Grouping always starts from the right for exactly this reason.
Two things this will not do. It reads the whole input as one number, separators and all, so it will not treat each group as a separate byte; if your bits are one character per group, binary to ASCII is the tool. And leading zeros are not printed, so 0011 0110 comes back as 36 rather than 036; zeros on the left carry width, not value, so pad the hex yourself where a fixed number of digits matters.
Questions
F, which is 15 in decimal.
The left. Padding on the right multiplies the value — 110110 padded left is 36, padded right it is D8.
Zeros are added on the left to complete the leftmost group, so six bits are read as eight.
Exactly four.
FF.
Leading zeros are not printed. 0011 0110 is 36, not 036 — pad it yourself if a fixed width matters.
No. Spaces, underscores and commas are ignored so you can paste grouped binary directly.