Hex to Binary Converter

What this tool is used for

• Expanding a bitmask or a register value so you can see which individual flags are set.
• Checking a permission or capability field where each bit has a documented meaning.
• Reading a hex-quoted protocol field down to the bit level while debugging a frame.
• Confirming an alignment or a power-of-two boundary by looking at the trailing zeros.
• Producing a bit pattern for documentation from a compact hex value.

Frequently Asked Questions

Why is this conversion so simple?

Because 16 is 2^4, each hex digit maps to exactly four bits independently — no arithmetic, no carries. A is 1010, F is 1111. This one-to-one grouping is the entire reason hex exists as a notation.

Should I keep the leading zeros?

Yes, when the width matters. 0x0A is 00001010, not 1010 — dropping the leading zeros loses the byte width, which matters for masks, protocol fields and fixed-width registers where position is meaningful.

How do I read a bitmask?

Convert to binary and read which positions are set. 0xF0 is 11110000, so it selects the high nibble; 0x0F selects the low. Permission and flag constants are almost always designed to be legible this way.

What is a nibble?

Four bits — exactly one hex digit, half a byte. The term is a deliberate pun on byte, and it survives in specs describing packed BCD and protocol headers where two values share a byte.

How wide should my output be?

Pad to a multiple of 8 for byte-oriented data, or to the register width (16, 32, 64) for hardware work. Unpadded binary is ambiguous about the underlying storage size, which matters when you are debugging alignment.

How do I use this to check a permissions value?

Convert to binary and read the bits against the flag definitions — each set bit is one permission. That is the practical use: hex is compact to store and binary is what you actually need to reason about.

Does the case of the hex digits matter?

No, `FF` and `ff` are the same value. Case matters only for consistency in output — mixed case in a dump is harder to scan, which is why tools pick one and stay with it.

Common errors and gotchas

• Dropping leading zeros within a nibble, which misaligns every bit position after it.
• Losing the total width. A 32-bit field needs its high zeros kept, or bit numbering shifts.
• Numbering bits from the wrong end. Documentation may count from the least significant bit or the most.
• Assuming byte order. Hex shows the value; it does not tell you how the bytes sit in memory.
• Reading a signed value's high bit as a flag when it is actually the sign in two's complement.