IPv6 to binary converter

The result expands all eight hextets and converts each one into exactly sixteen binary digits, preserving leading zeroes. You receive both a readable space-grouped representation and one continuous 128-bit value, making the output useful for networking lessons, prefix comparisons, subnet exercises, documentation, and exact programmatic checks without manual hexadecimal arithmetic.

How hexadecimal IPv6 becomes 128 binary bits

An IPv6 address contains 128 bits divided into eight hextets. Each hextet holds four hexadecimal digits, and every hexadecimal digit maps to exactly four binary digits. That makes one complete hextet sixteen bits wide and the eight-hextet address exactly 128 bits wide. The converter first expands the input to eight groups of four hexadecimal characters, then converts each group independently while retaining every leading zero. For example, the hextet 0001 becomes 0000000000000001, not simply 1. Keeping that fixed width is essential because the position of a bit carries meaning in an address. The binary_groups field provides eight separate sixteen-bit strings, while binary joins those groups with spaces for reading. The binary_128 field removes the separators for software or worksheets that require one continuous bit string. The expanded address and hextets fields let you trace each binary group back to its hexadecimal source, so the conversion remains easy to audit rather than appearing as an unexplained wall of digits.

Using the result to understand prefixes and masks

IPv6 prefixes select a number of bits starting from the left side of the 128-bit address. A /32 prefix selects the first two binary hextets, a /48 selects the first three, and a /64 selects the first four. Prefix lengths that are not multiples of sixteen stop inside a hextet, which is where a full binary view becomes especially helpful. With a /52, for instance, the network portion contains three complete hextets plus the first four bits of the fourth hextet. You can place two converter outputs side by side, count from the left, and see exactly where their network bits agree or differ. The tool performs conversion only; it does not apply a CIDR mask or claim that two addresses share a network. This deliberate separation makes it suitable for teaching because learners can mark the boundary themselves. For production membership checks, use a dedicated prefix checker after understanding the representation. Always count the continuous binary_128 value when precision matters, since spaces in the readable binary field are visual hextet separators and do not consume bits.

Accepted notation, normalization, and input errors

You may enter standard compressed IPv6 notation, fully expanded notation, or an IPv6 address with an embedded dotted-decimal IPv4 ending. A double colon may replace one run of one or more zero hextets, and leading zeroes may be omitted within individual hextets. The converter normalizes all accepted forms into lowercase, eight-hextet expanded notation before producing binary. Strict validation prevents a plausible-looking but incorrect result. Multiple double-colon markers, too many or too few groups, hexadecimal groups longer than four characters, non-hexadecimal characters, and invalid IPv4 octets are rejected. A bare IPv4 address is not silently treated as IPv6. CIDR suffixes such as /64 are also rejected because this capability converts an address rather than a network expression. Zone identifiers such as %eth0 are excluded because they describe local interface scope and are not part of the 128 address bits. When an error occurs, correct the address syntax and submit it again; the converter never guesses missing structure beyond the compression rules defined for IPv6.