IPv6 to Binary Converter
all 128 bits, and where your prefix falls

What the result shows

Most pages that convert IPv6 to binary hand back one long string and stop. The string is the easy part. What you wanted it for is almost always a bit position: which bits a prefix covers, where a subnet boundary lands, whether two addresses differ before bit 64 or after. A bare run of digits answers none of that.

So every converted line comes back as four verdict tiles, the bits themselves, and a breakdown. The first tile says how many bits were printed and reconciles the number two ways: eight groups of sixteen, thirty-two digits of four. It also counts the ones and the zeros, because a bit count is the one thing this kind of tool cannot get wrong and still be useful.

The second tile names the address from the IANA IPv6 Special-Purpose Address Registry shipped inside the page, with the reachability it records. The third reports the prefix length and where its boundary lands. The fourth is a round trip: the 128 bits are read back into eight groups by a separate path and compared, so a disagreement shows as a warning rather than a plausible wrong answer. The guide on what an IP address is and how it works starts further back than this page does.

Below the tiles sit all 128 bits as one selectable run, then the address group by group. Each group shows its four hexadecimal digits and, under each, the four bits that digit stands for. Supply a prefix length and all thirty-two digit cells are marked network, host or split, the split one saying how many of its four bits fall on each side.

Last comes the same address in every other notation: the RFC 5952 canonical form, the expanded form, the 32 hexadecimal digits, and the address as one 128-bit decimal integer. If what you have is IPv4, that conversion lives on the IPv4 binary converter, which adds eight place values per octet instead of looking up four bits per digit.

Every format this IPv6 to binary converter accepts

An IPv6 address arrives in whatever shape produced it: compressed from a router, expanded in a spreadsheet, bracketed with a port in a log, or carrying a zone identifier from a Windows machine. All name the same 128 bits, so all are accepted. Here is the contract in full rather than something to discover by trial.

Two refusals are deliberate. A second double colon is refused rather than guessed at, because the number of zero groups each stands for then becomes impossible to work out. An embedded IPv4 octet with a leading zero is refused too: a leading zero means octal to a great deal of software, and reading it two ways is how access-control bugs happen.

Whatever shape goes in, the result reports what it did with it. A leading zero inside a group is legal on input and carries no value, so it is read and then reported — RFC 5952 section 4.1 requires leading zeros to be suppressed on output and a single 16-bit zero field to be written as 0. Uppercase is lowercased, because section 4.3 makes the canonical form lower case. To convert IPv6 address to binary is only half of what people want from these notations; for the shortening or the writing out alone, the compressor handles canonical and expanded form.

One hexadecimal digit is four bits

This is the whole of the IPv6 to binary conversion, and it is a different operation from the IPv4 one. To convert IPv6 hex to binary you replace each digit with its four bits. There is no adding up: an IPv4 octet is eight place values added together, while a hexadecimal digit is a lookup in a table of sixteen rows. Here is the table.

A four-bit chunk has a name: a nibble, half a byte. An IPv6 group is four of them, sixteen bits, which is why the group is also called a hextet. Eight hextets is 128 bits; thirty-two nibbles is the same 128 bits. Moving between those two ways of slicing one address is most of what reading IPv6 by hand consists of, so the tool prints both views side by side.

RFC 4291 section 2.2 describes the text form as one to four hexadecimal digits for each of the eight 16-bit pieces. The damage is done by “one to four”. A group may be written with fewer than four digits, so people convert the digits they can see. db8 is three digits and twelve bits, but the group it names is 0db8, and the four dropped bits were real.

The same slip in reverse is worth naming. A group is sixteen bits, not sixteen digits. Treating it as digits makes the address 512 bits long and every prefix calculation wrong. If the notation itself is the unfamiliar part, the walkthrough on what an IPv6 address is starts before any of this.

Where a prefix length actually falls

This is the question people arrive with, and it is why the prefix length is an input here rather than a paragraph. A prefix of length n covers bits 1 to n from the leftmost bit. A /64 covers the first four groups, the first sixteen hexadecimal digits. A /61 stops one bit into the sixteenth digit, and the tool marks that digit split. It also gives the network address, the last address in the range, and how many addresses that is.

Because a hexadecimal digit is four bits, a prefix length that is a multiple of four lands on a digit boundary and one that is not lands inside a digit. It is the same arithmetic as an IPv4 subnet mask, where 255.255.254.0 is a /23 and not a /24 for exactly this reason. The explanation of what a subnet mask really counts is the IPv4 version of this paragraph.

The fields the boundary cuts through

A prefix length is not only a bit count; it lands inside a structure the standards define. The tool prints that structure for the kind of address you gave it, with the widths taken from each RFC's own diagram, and marks the field the boundary falls in.

The global unicast row is what makes /64 the number everyone assumes: all global unicast addresses other than those starting with binary 000 have a 64-bit interface identifier, so n + m is 64. Give the tool a /48 and it says bits 49 to 64 are yours to number subnets with. Give it a /127 and it says the prefix has reached into the interface identifier, which is legal and on router links required.

The nibble boundary is a convention, not a rule

You will read that an IPv6 prefix must be a multiple of four, usually with an RFC number attached. That is not what the standards say, and the number attached is usually RFC 5375 — a document in which the word “nibble” does not appear at all.

What the standards say runs the other way. RFC 7608 section 2, which is BCP 198, requires that forwarding “MUST be designed to process prefixes of any length up to /128, by increments of 1”. RFC 6177 mentions the nibble boundary once, as something that “should be given adequate consideration”. The recommendation people are remembering is an operator document, RIPE-690: the length of a delegated prefix should always be a multiple of 4.

So the convention is real and sensible — four-bit alignment keeps reverse DNS delegation tidy and prefixes readable — but it is about prefix delegation, not about what an address or a router can do. A /61 is valid, and so is a /65. For the arithmetic across a whole allocation rather than one address, that is the subnet calculator's job.

Counting to 128, and why some converters stop short

Seven pages that rank for IPv6 to binary were read in full while this tool was planned, and the bits in their own published examples were counted. The page in first position on four of five queries prints 119 bits for a 128-bit address. The page in second position on the same four prints 85, because each zero group comes out as a single 0 — on a page whose own text states that IPv6 is 128 bits.

That is not a rounding error; it is the whole answer being wrong. Every bit after the first dropped zero has moved, so counting to position 64 on a 119-bit string lands somewhere else, and there is no way to tell. Feed a short string into a binary to IP converter and it cannot rebuild the address either, because the information has gone.

The cause is always the same. Leading zeros are suppressed in the text form, correctly, because RFC 5952 requires it, and then the converter works from the suppressed digits. A group written 0 becomes one bit instead of sixteen; db8 becomes twelve. Do that to an address with two zero groups and 43 bits are gone, which is exactly the shortfall in the 85-bit example.

The fix here is structural rather than careful: the bits come from the sixteen bytes of the address, never from the text, so no group can contribute fewer than sixteen. Then the count is printed and reconciled. Any 128 bit binary output should be checkable against its own stated length, so if a page shows an IPv6 address in binary without saying how many bits it printed, count them.

Bit positions matter beyond conversion: they are how header fields are laid out and how a router decides what to read. The comparison of the IPv4 and IPv6 headers is the same counting done on the packet instead of the address.

Six mistakes this tool catches

1. Converting the digits you can see

The commonest error in IPv6 binary conversion, and the one that produces short output. Expand to four digits per group first. The tool reports when a group arrived with leading zeros, so the padding is visibly restored.

2. Turning a zero group into a single zero bit

A group of 0 is sixteen zero bits. A double colon is not one zero either: it stands for however many whole zero groups are missing, which is why only one is allowed. The tool restores the run, says what it stood for, and refuses a second.

3. Counting a group as sixteen hexadecimal digits

Sixteen bits, four digits. An address is 32 hexadecimal digits in total, not 128.

4. Assuming a prefix length must divide by four

It does not, and RFC 7608 requires routers to handle every length. The tool takes any length from 0 to 128 and shows the digit a non-aligned one splits.

5. Counting the prefix from the wrong end

A prefix counts bits from the left, as a subnet mask does. A /64 is the first 64 bits, not the last. The tool prints the network part and the host part as separate runs, so there is nothing to count by eye.

6. Treating a zone identifier or a port as part of the address

Neither contributes a bit. A zone identifier means something only on the host that wrote it, and a port belongs to the socket rather than the address. Both are accepted, both set aside, and the result says so instead of dropping them silently.

What this tool does not do

It converts whole addresses. A fragment is not an address, so a partial group count is refused with the count it found rather than padded out.

It does not touch the network. There is no reverse lookup, no ping and no ownership data, because everything happens in your browser. The block name comes from a registry table shipped inside the page, so it is only as current as the day it was read: 25 September 2026, when the IANA registry listed 25 rows.

It does not go the other way, do IPv4, or decode transition mechanisms. Each has its own page, linked above.

One honest limitation about this build: the arithmetic, the refusals and the rendered result have all been tested in a real document object model, and every node the page produces inspected. But no browser has drawn the page, so nothing is known about how it paints — the nibble grid at phone width, the focus rings, the contrast. If something looks wrong rather than reads wrong, that is why.

Frequently asked questions

Does an IPv6 prefix length have to be a multiple of four?

No. RFC 7608 is explicit in the other direction: forwarding “MUST be designed to process prefixes of any length up to /128, by increments of 1”. A /61 or a /65 is perfectly valid and this tool will show you exactly which hexadecimal digit it splits. The four-bit habit is an operational convention for delegation and reverse DNS, written down in RIPE-690 as “the length of a delegated prefix should therefore always be a multiple of 4”. It is not a protocol rule, and no RFC requires it.

Why is IPv6 written in hexadecimal if the address is binary?

Because 128 binary digits are unusable by hand and hexadecimal is the shortest notation that maps cleanly onto them. One hexadecimal digit is exactly four bits, so 32 digits cover 128 bits with no remainder and no arithmetic — each digit is a straight lookup, not a sum. RFC 4291 settled on that notation in section 2.2 for exactly this reason. Decimal does not divide evenly into bits, which is why IPv4’s dotted decimal needs place-value addition and IPv6 does not.

How does a zero group appear in binary?

As sixteen zeros, every time. This is where converters go wrong: a group written 0 in text is still 0000000000000000 in binary, and a group written db8 is 0000110110111000, not 110110111000. Dropping the leading zeros is correct in the text form and wrong in the binary one, because the binary form is about bit positions. An address with two zero groups loses 32 bits that way, which is how a 128-bit address ends up printed as 85 bits.

Which bits does a /64 actually cover?

Bits 1 to 64, counting from the leftmost bit of the address — the first four groups, or the first sixteen hexadecimal digits. Everything from bit 65 onwards is the interface identifier. RFC 4291 section 2.5.4 puts it as a global routing prefix of n bits, a subnet ID of m bits and a 64-bit interface ID, with n + m = 64 for all global unicast addresses that do not start with binary 000. Paste an address with /64 on it and the tool marks the boundary on the bit itself.

How many bits is one hexadecimal digit?

Four, always. That gives sixteen possible values, 0 to f, and it is why the mapping is fixed rather than calculated: 0 is 0000, 7 is 0111, a is 1010, f is 1111. A 16-bit group is therefore four digits, an address is 32 digits, and 32 × 4 is 128. The common slip is to treat a group as “16 hex” rather than 16 bits, which quadruples the address to 512 bits and makes every prefix calculation wrong.

Can I paste brackets, a port or a zone identifier?

Yes, and the tool tells you what it did with each. Square brackets and a port come from URL syntax, so [2001:db8::1]:443 is read as the address with the port set aside. A zone identifier like %eth0 is local to one host under RFC 4007 section 11, so it is set aside too. Neither contributes a single bit to the 128, and the result says so rather than dropping them quietly. A prefix length can go on the line or in its own box.