Expand a hexadecimal string into its underlying binary representation. Each hex digit becomes a fixed 4-bit nibble, with leading zeros kept so 8-bit byte boundaries line up cleanly. Useful for reading hex dumps, debugging color codes, and CTF puzzles.

Hex ⇄ Binary Converter

Mode:
Options:
0 / 100,000 chars

How hex to binary works

The converter scans the hex string one character at a time, looks up the 4-bit binary pattern for each digit, and concatenates the results. F1111, 00000, A1010. Whitespace and 0x prefixes are removed first so they do not interfere.

Quick examples

HexBinary
A1010
FF11111111
1F00011111
0xABCD1010101111001101
FF6600111111110110011000000000

How to use

  1. Paste hex characters (0-9, A-F, upper or lower case) into Input. A leading 0x and any spaces are stripped automatically.
  2. The binary expansion appears in Output. Every hex digit becomes exactly 4 bits, leading zeros included.
  3. To convert back, click Binary → Hex at the top of the converter, or use Swap.
  4. Click Copy for the result. All work is done locally in your browser.

Real-world use cases

  • Pulling apart CSS colours. A value like #FF00FF is three bytes — one each for red, green, and blue. Expanding it to 11111111 00000000 11111111 shows the per-channel 8-bit pattern at a glance, useful when you want to reason about colour blending or alpha masks in bits rather than hex.
  • Reading MAC addresses. Every pair of hex digits in a MAC is one byte, so a 12-digit address expands to 48 bits split into six bytes. Spelling out the bits is the quickest way to find the locally-administered bit or the multicast bit inside the first octet.
  • Decoding hex dumps. A dump like 48 65 6C 6C 6F turns into five bytes of binary, which the reverse binary translator reads back as "Hello". Useful for sanity-checking forensic captures or protocol traces.
  • CTF challenges. Many puzzles hide flags inside a hex payload where the trick is a bit-level pattern — XOR keys, alternating bits, or specific masks. Expanding to binary makes those patterns visible without doing the maths in your head.
  • Embedded register bits. Datasheets describe peripheral registers in hex, but the meaning lives in individual bits (enable flag here, interrupt mask there). Converting 0x3A to 00111010 lines up each bit with the field table in the documentation.
  • Inspecting opcode encodings. ARM and x86 instructions printed as hex hide the bitfields that name registers, addressing modes, and condition codes. Drop a hex opcode into the converter and the field boundaries become obvious.

Each hex digit is exactly 4 bits

Hexadecimal is base 16, and 16 happens to be 24. That single fact is why hex is the everyday shorthand for binary data: each hex digit maps to exactly four bits, with no rounding and no ambiguity. 0 is 0000, F is 1111, and every value in between fills the table cleanly.

Full 0–F lookup table
HexBinaryHexBinary
0000081000
1000191001
20010A1010
30011B1011
40100C1100
50101D1101
60110E1110
70111F1111

The converter accepts input in whatever shape you have it: a leading 0x (or 0X) is stripped, spaces are ignored so pasting a hex dump with byte separators works, and upper- and lower-case digits are treated as the same value. That makes the tool tolerant of copy-pastes from debuggers, terminals, and documentation without forcing you to clean the string first.

A short historical note explains why hex won. Before byte sizes were standardised, computers used word lengths of 6, 12, 18, or 36 bits, and octal (base 8, three bits per digit) was the natural fit. When IBM's System/360 family in 1964 fixed the byte at 8 bits, octal stopped lining up cleanly — three doesn't divide eight — while hex did: two hex digits to a byte, exactly. Within a decade hex had displaced octal as the default compact notation for raw binary data, and it has stayed there. Going the other direction (binary to hex) collapses every four bits back into one hex digit, so the two converters are inverses.

Worked examples

A few short conversions show how the rules behave in practice.

Single digit: A

A is the tenth value (counting from zero), so its 4-bit pattern is 1010. One hex digit always gives four bits — no padding question to answer.

One full byte: FF

Two F digits give 1111 twice, producing 11111111. That is the largest value an unsigned 8-bit byte can hold (255 in decimal).

Prefix + mixed case: 0xDEADBEEF

The 0x is stripped, the remaining eight digits are case-folded, and each one expands to four bits, giving 32 bits in total: 11011110 10101101 10111110 11101111. The same input as 0xdeadbeef or DeadBeef produces an identical result.

Hex dump with spaces: 48 65 6C

Spaces are dropped before parsing, so the converter sees 48656C and emits 01001000 01100101 01101100 (shown here with byte gaps for readability; the actual output is one continuous bit string). Those three bytes are the ASCII codes for "Hel".

Common pitfalls

  • Stray non-hex characters. Anything that is not 0–9 or A–F (G, H, punctuation, smart quotes pasted from a PDF) makes the converter refuse the input rather than guess. The error message names the offending character so you can find it quickly.
  • 0x prefix in unexpected places. Stripping is a global, case-insensitive replace: 0x and 0X are both removed, regardless of position in the string. That is forgiving for normal pastes, but it does mean a value like A0xB becomes AB. If that matters, scrub the prefix manually.
  • Colons inside IPv6-style hex. Addresses like fe80::1 use colons as separators, and this tool does not strip them — only whitespace and the 0x prefix are skipped. Pass fe80::1 through a search-and-replace to remove the colons first.
  • Assuming case sensitivity. ff, FF, and Ff are identical to the converter. If you need a specific case in the surrounding hex notation, that is a formatting decision to make outside the tool.
  • Wanting nibble-level spacing in the output. The result is a continuous bit string with no separators. To group every four bits or every byte, split the output manually or round-trip through the binary to hex converter to re-collapse the groups.

Frequently asked questions

Does case matter? Can I paste FF or ff?

Either works. The converter normalises hex characters before expanding, so FF, ff, and Ff all become 11111111.

Is the 0x prefix accepted?

Yes. Both "0xFF" and "FF" produce the same result — the prefix is stripped automatically (along with whitespace) before parsing. The match is case-insensitive, so 0X also works, and any occurrence of "0x" anywhere in the string is removed.

Why does a single hex digit expand into 4 binary bits — never 3 or 5?

One hex digit can represent 16 distinct values, and 2⁴ = 16. So every hex digit needs exactly 4 binary positions to encode it without ambiguity. F = 1111, 0 = 0000.

Are leading zeros preserved in the output?

Yes. Each hex digit always expands to 4 bits, including the first one. "1F" → "00011111", not "11111", so byte boundaries stay intact.

Can I expand a hex color code like #FF6600?

Strip the # first, then paste FF6600. The output 111111110110011000000000 is the 24-bit RGB binary. Bytes can be read in 8-bit pairs from the left.

What characters count as valid hex digits?

0–9 and A–F (or a–f). Anything else — including colons, dashes, "G", "H", or punctuation — is rejected. Whitespace and the "0x" prefix are the only non-hex tokens that get stripped silently.

How are non-hex characters handled?

The converter refuses to guess. If your input contains a character outside 0–9 / A–F, the tool reports the offending character so you can locate the typo. Colons in IPv6-style addresses (e.g. "fe80::1") fall into this bucket — strip the colons first.

Does the output insert spaces between bytes?

No. The expansion is a continuous bit string. If you need 8-bit groups for readability, split the result manually after every eighth character, or paste the binary into the reverse converter to see it normalised.