Binary to IP Converter
with the arithmetic shown, bit by bit

What the result shows

Most tools that convert binary to IP give you one thing: the dotted-decimal string. That is the answer you asked for, and the least interesting part of it. The moment you have it you want something else — whether the number is right, what kind of address it is, or how to write it down without breaking it.

So each converted line comes back as four verdict tiles and two tables. The tiles are the address itself, the family with the reason that family was chosen, the block the address belongs to, and whether the round trip matched. That last one is not decoration: the tool converts its own answer back into binary along a separate code path and compares the two strings. If those ever disagree, something is wrong and you should not trust the row.

The block comes from the IANA Special-Purpose Address Registries, one for each family. It is the difference between an address you can route and one you cannot, and it is the reason 10.0.0.1 and 8.8.8.8 are not interchangeable even though both are perfectly valid. If the registry has nothing to say about an address, the tool says it is ordinary unicast rather than inventing a label. For the wider picture of what an address is and where it comes from, the guide on what an IP address is and how it works covers the ground this page assumes.

Underneath sit the other notations. The same 32 bits are also a single unsigned integer, four pairs of hex digits, and four octal numbers, and each one turns up in a different place: integers in databases and log files, hex in packet dumps, octal almost nowhere except by accident. Each row links to the converter that owns that direction, so the wrong notation in hand is one click from the right page. The reverse trip — an address in, binary out — is the IP to binary tool.

The quickest way to convert binary to IP address form in quantity is to paste the whole column at once. Up to fifty lines are read in one pass, and a line that fails says why on its own row instead of stopping the others. The single-integer form of the same address, the one that shows up in database columns and log files, lives on the decimal converter.

Every format this binary to IP converter accepts

Binary arrives in whatever shape the thing that produced it felt like. A packet-analyser dump uses spaces. A textbook uses dots. A programming exercise hands you one unbroken run. Somebody typing from memory leaves the padding off. All of those mean the same address, so all of them are accepted, and here is the contract in full rather than as a guess you have to make. If the notation itself is the unfamiliar part, how to read an IP address format starts further back than this page does.

Commas, semicolons, hyphens and underscores work too. A run of spaces counts as one separator, and a space next to a dot is absorbed into it, because whitespace cannot mean anything else in a number. What is not accepted is two punctuation separators in a row: 11000000..10101000.1.1 might be four groups, or five with one left out, and this page does not guess when guessing would change the answer.

The family is decided by counting, never by looking at the values. Four groups is IPv4, eight or sixteen is IPv6, and one unbroken run has to be exactly 32 or 128 bits. Anything else is refused with the count it found, which beats a red box. So a 32 bit binary to IPv4 address conversion works from any of the first five shapes above, and none of them changes the result by a single bit.

How eight bits become one number

An octet is eight positions, and each position is worth twice the one to its right. From left to right they are 128, 64, 32, 16, 8, 4, 2 and 1. To read an octet you add the values of the positions that hold a 1 and ignore the rest. That is the whole of binary to decimal conversion for an IP address, and why the tool prints the weights above the bits rather than only the total.

Two facts fall straight out of that table. The largest octet is 255, because adding all eight weights gives 255 — not 256. And the smallest is 0, when no position holds a 1. So every octet is somewhere in 0 to 255, every IPv4 address is somewhere in 0.0.0.0 to 255.255.255.255, and there are exactly 256 possible values per octet because zero is one of them. The difference between the largest value and the number of values is where most of the confusion about 256 comes from.

The weights also explain why a subnet mask is only ever a run of 1s followed by a run of 0s, and why every mask table counts 128, 192, 224 and upwards — each number is one more bit from the left. The write-up on IP address classes A to E walks through where those boundaries came from.

Doing this by hand once, deliberately, is the only way the mask arithmetic becomes obvious. After that a binary to IPv4 conversion is clerical work. The place-value table stays on screen so you can check the tool rather than trust it.

The leading zero that changes the address

Here is the part the pages that rank for this keyword leave out. Once you have your four numbers, how you write them down matters, and one very natural habit quietly changes the address.

People pad. Columns line up better, log files sort properly, and 010.001.001.001 looks tidier than 10.1.1.1. But in the grammar POSIX defines for inet_addr, a leading zero means the number is octal. Octal 10 is eight. So the tidy version of 10.1.1.1 is a different address, and nothing warns you.

Those last three are not invented examples. RFC 6943 section 3.1.1 prints exactly that trio and says they “all represent the same IPv4 address” in what it calls the loose syntax of an address literal, as against the strict form that inet_pton uses. The measurement above reproduces the RFC's own claim on a real machine, which is a more useful thing to show you than a paragraph asserting it.

The strict side has a grammar you can read. RFC 3986 section 3.2.2 defines each part as a dec-octet, and its rule requires a two-digit part to begin with 1 to 9 and a three-digit part with 1 or 2. A leading zero simply does not match, which is why the strict parsers refuse rather than reinterpret. The POSIX definition of inet_addr is where the other reading comes from: it states that a leading 0 implies octal, and it also allows fewer than four parts, which is what makes both 10.0.258 and the bare 167772161 legal spellings.

This is not trivia. Three CVEs have been issued for software that read these strings differently from the system it was guarding. CVE-2021-29921 records that Python's ipaddress library “mishandles leading zero characters” in a way that “allows attackers to bypass access control that is based on IP addresses”. CVE-2021-28918 and CVE-2021-29418 cover the same class of bug in a widely used Node package, the first producing server-side request forgery and file-inclusion attacks. A validator that reads 010.1.1.1 as ten and a firewall that reads it as eight is a hole, and it looks like a typo.

So the results panel computes the padded reading for whatever you convert, and where the padded form is not legal octal at all — any octet containing an 8 or a 9, because neither is an octal digit — it says that instead of a number. The octal notation itself, used deliberately rather than by accident, belongs to the octal converter.

128 bits, and why IPv6 is not the same sum

A 128 bit binary to IPv6 conversion looks like the same job four times over. It is not, and treating it as one is how people end up with addresses that are almost right.

RFC 4291 section 2.2 says an IPv6 address is written as “eight 16-bit pieces”, each of “one to four hexadecimal digits”. A hexadecimal digit is exactly four bits. So the operation is not place-value addition across a group — it is chopping each group of sixteen bits into four nibbles and turning each nibble into one hex character. The tool shows that mapping nibble by nibble, because it is a different mental move from adding up an octet.

Then there is the spelling. One address has many legal written forms, and RFC 5952 picks one to be canonical: no leading zeros inside a group, lowercase letters, and the longest run of zero groups replaced by a double colon. The tool prints both the canonical form and the fully expanded one, because you need the long form to line addresses up and the short form for a config file.

Two prefixes carry an IPv4 address in their last 32 bits, and for those the tool writes the tail in dotted decimal and reads the embedded address out for you. Everything else is left as hexadecimal, including the old ::a.b.c.d form, which RFC 4291 deprecated and which RFC 5952 does not permit a dotted tail for. Some command-line tools still dot it. This one follows the standard and says which it is doing.

Six mistakes this tool catches

1. A bit count that is close but not right

Thirty-one bits and thirty-three bits both look like thirty-two on screen. A tool that quietly pads or truncates gives you a real-looking address that is wrong, usually in the last octet. This one counts and tells you the number it found.

2. Using 256 as a place value

It turns up in notes and in forum questions, and it is always wrong. Eight bits reach 255. The doubling sequence inside an octet stops at 128 on the left, and 256 would need a ninth position.

3. Padding the answer with zeros

Covered in full above. The short version: the tool shows you what the padded form would be read as, so the trap is visible before you paste the address into a firewall rule.

4. Counting mask bits from the wrong end

The prefix length counts 1s from the left. A mask of 255.255.254.0 is 23 bits, not 24, because the third octet is 11111110 — seven 1s and a 0. Converting the mask to binary makes it countable instead of memorable, and the subnet calculator takes it from there.

5. Assuming every zero group in IPv6 can be collapsed

Only one run may become a double colon, and a run of a single zero group is left alone. Two double colons make an address ambiguous, which is why the standard forbids them. The canonical form the tool prints already applies the rule, so copying it is always safe.

6. Pasting an address that is already decimal

10.0.0.1 is a real IPv4 address and it is also legal binary, because every character in it is a 0 or a 1. Read as binary it means 2.0.0.1, and 10.11.100.101 means 2.3.4.5. The tool gives the binary reading, which is its job, and then says plainly that the line you pasted is an address in its own right — so a wrong answer cannot pass for a right one.

What this tool does not do

It converts whole addresses only. A partial bit string is not an address, so a prefix or a mask fragment is refused rather than padded out to something plausible.

It does not touch the network. There is no ping, no reverse DNS and no ownership data, because the whole conversion happens in your browser and nothing you paste is transmitted anywhere. The block name in the result comes from a registry table shipped inside the page, not from a query. Which company holds the address, and where it is announced from, needs a tool that actually queries something.

It does not plan subnets, and it does not go from an address back to binary. Both have their own pages, 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, but no browser has drawn the page. Nothing is known about how it paints. If anything looks wrong rather than reads wrong, that is why.

Frequently asked questions

Does the binary have to be exactly 32 bits?

For IPv4, yes — once the groups are assembled. An IPv4 address is 32 bits, so 31 or 33 cannot be one. What you do not have to do is pad every group by hand: leading zeros in a binary numeral carry no value, so 1.10.11.100 and 00000001.00001010.00001011.01100100 are the same address. The tool pads each group for you and tells you how many zeros it added. For IPv6 the count is 128.

Do I need the dots between the octets?

No. One unbroken run of 32 binary digits works, and so do dots, colons, spaces, tabs, commas, semicolons, hyphens and underscores, in any mix. A run of spaces counts as one separator and spaces beside a dot are absorbed into it, because neither can mean anything else. Two dots in a row are refused rather than guessed at: 11000000..10101000.1.1 could be four groups or five with one missing.

Why does 010.010.010.010 not mean 10.10.10.10?

Because a leading zero means octal in the grammar POSIX defines for inet_addr, and octal 10 is eight. The result panel computes this for whatever address you convert. Measured here on 27 September 2026 against the glibc 2.39 resolver: 010.1.1.1 resolves to 8.1.1.1. The strict grammar in RFC 3986 forbids the leading zero outright, which is why some libraries refuse the same string that others silently re-read.

Can I convert 128-bit binary to an IPv6 address?

Yes. Give it 128 binary digits as one run, as eight 16-bit groups, or as sixteen bytes, and it returns the RFC 5952 canonical spelling and the fully expanded one. IPv6 is not built from place-value addition the way an IPv4 octet is: each group of four bits becomes one hexadecimal digit, which is why RFC 4291 calls an address “eight 16-bit pieces” of “one to four hexadecimal digits”. The tool shows that mapping nibble by nibble.

What happens if one group is longer than 8 bits?

It is refused, and the refusal names the group and its width. An octet holds eight bits and a hextet holds sixteen, so a nine-bit group in a four-group input is not a padding question, it is a typo or a miscount. The same applies to a seventeen-bit group in an eight-group input. Silently truncating or wrapping would produce a plausible-looking address that is simply wrong, which is worse than an error message.

Why is 256 not one of the bit values?

Because eight bits only reach 255. The place values in an octet are 128, 64, 32, 16, 8, 4, 2 and 1, and adding all eight gives 255 — which is why that is the largest octet and 255.255.255.255 the largest IPv4 address. 256 is what you get from nine bits, and it appears in people’s notes because the count of values an octet can hold is 256: zero through 255.