To convert a 32-bit binary IPv4 address to dotted-decimal notation, group the 32 bits into four consecutive 8-bit octets from left to right and write each octet as its decimal value between 0 and 255, separated by periods. The dotted-decimal form is a more readable presentation of the same 32-bit pattern the binary string represents, and the unsigned 32-bit integer is yet another way to present the same 32 bits. Conceptually, an IPv4 address a.b.c.d corresponds to the integer a × 256³ + b × 256² + c × 256 + d, so 192.168.1.1 equals 192 × 16,777,216 + 168 × 65,536 + 1 × 256 + 1 = 3,232,235,777. Once you have that integer, the path back to dotted-decimal is straightforward arithmetic that any safe-integer calculator can perform without floating-point loss. The IP to Decimal Converter does this last step for you, splitting an unsigned integer from 0 through 4,294,967,295 into exactly four base-256 components in the browser, with no rounding and no network requests.
The Binary, Integer, and Dotted-Decimal Forms Describe the Same 32 Bits
An IPv4 address is defined in RFC 791 as a 32-bit quantity, and any representation of it — dotted decimal, plain unsigned integer, hexadecimal, or binary — is just a different way of writing those same 32 bits. The dotted-decimal form writes the address as four octets separated by periods, where each octet is the unsigned decimal value of eight consecutive bits. The binary form writes those same 32 bits as zeros and ones, often grouped into four groups of eight for readability. The unsigned 32-bit integer form reads the same 32 bits as one base-2 number and writes it in base 10.
Because all three notations describe the same 32-bit value, converting from binary to dotted decimal reduces to two operations. First, read the 32 bits as a single unsigned binary number and convert that number to its unsigned decimal equivalent, which lands somewhere between 0 and 4,294,967,295. Second, take that decimal integer and split it back into four base-256 components — the most significant byte first, then the next, then the next, then the least significant byte.
The first operation is what every binary-to-decimal tutorial teaches. The second operation is what the IP to Decimal Converter performs, and it is the part that is easiest to get wrong by hand because of carrying and byte-order mistakes across the same boundary that causes big-endian and little-endian confusion in other contexts. The dotted form is defined by RFC 791 to put the most significant octet first, so the conversion is fixed: there is no little-endian variant to remember, and the order in which you write the four groups is always the same as the order of the bits you read.
Convert a Binary IP Address to Four Octets
- Locate or paste the 32-bit binary string for your IPv4 address, with or without periods or spaces separating the four octets.
- Read the 32 bits as one unsigned binary integer. If you would like a refresher on the binary-to-integer arithmetic, see the related walkthrough on converting a binary IP address to a decimal integer, or use any verified binary-to-decimal calculator.
- Open the IP to Decimal Converter and switch the direction to decimal-to-IPv4.
- Paste the unsigned integer into the input field without spaces, signs, decimal points, leading zeroes, or any trailing characters.
- Click Convert and read the four-octet dotted-decimal result displayed by the tool.
- Copy the result into your destination — database column, configuration file, log entry, or test fixture — and confirm the destination stores it as an unsigned 32-bit type, a wider integer, or a validated decimal string.
The tool does not accept binary directly; it expects a decimal integer as input on the integer side. That is by design, because the strict integer parser inside the converter catches the kinds of input that hand-written binary parsers usually miss — values outside the 0 to 4,294,967,295 range, missing octets, negative signs, hexadecimal notation, and ambiguous leading zeroes. Working through the integer form also keeps the tool small and fast, relying entirely on integer arithmetic within JavaScript's exact safe-integer range so every IPv4 value from 0 through 4,294,967,295 is represented without floating-point rounding.
Why the Tool Avoids Rounding and Octal Ambiguity
Floating-point arithmetic is a common source of silent errors in IP conversion routines, which is why this tool relies entirely on integer arithmetic within JavaScript's exact safe-integer range so every IPv4 value from 0 through 4,294,967,295 is represented without floating-point rounding. The IP to Decimal Converter performs the conversion entirely with integer arithmetic inside JavaScript's safe-integer range, so every IPv4 value from 0 through 4,294,967,295 is represented exactly. There is no rounding step, no IEEE-754 conversion, and no precision loss at the boundary of the 32-bit range.
Octal ambiguity is a second, older problem. Several legacy parsers and languages interpret a leading zero on a numeric token as a base-8 prefix, so 010.0.0.1 has historically been read as decimal 8.0.0.1 in some environments and as decimal 10.0.0.1 in others. The tool sidesteps that ambiguity by rejecting any input octet that carries a leading zero at all, so 010.0.0.1, 192.168.001.1, and 001.002.003.004 are all refused before any arithmetic begins. The value 0 itself is still allowed, because the literal single digit zero has no leading-zero digit to disambiguate.
These strict rules cover the cases that silently produce wrong answers in hand-written code: missing octets, octets above 255, signed integers, fractions, hexadecimal notation, surrounding whitespace, and CIDR suffixes. A value such as 192.168.1.1/24 is rejected outright instead of being silently truncated to 192.168.1.1, because CIDR prefixes change the meaning of the address and belong to a different calculation. The same strictness applies in the reverse direction, where a decimal value such as 4294967296 is refused because it exceeds the unsigned 32-bit ceiling, and a value like 007 is refused because the leading zero would be ambiguous across parsers.
Forms the Tool Accepts and Rejects
| Input form | Example | Result |
|---|---|---|
| Plain dotted-decimal IPv4 | 192.168.1.1 | Accepted |
| Plain unsigned 32-bit integer | 3232235777 | Accepted |
| IPv4 with surrounding spaces | " 192.168.1.1 " | Rejected |
| IPv4 with leading zeroes | 192.168.001.1 | Rejected |
| IPv4 with a CIDR suffix | 192.168.1.1/24 | Rejected |
| Negative integer | -1 | Rejected |
| Decimal value above 4294967295 | 4294967296 | Rejected |
| Hexadecimal notation | 0xC0A80101 | Rejected |
The tool is intentionally narrow. It handles individual IPv4 addresses only; it does not parse CIDR prefixes, subnet masks, port numbers, hostnames, IPv6 addresses, or arbitrary-size integers. A hostname such as example.com or a 128-bit IPv6 string is rejected rather than silently ignored. For network and broadcast boundaries or host counts, use a Subnet Calculator instead. For an RFC 4291 IPv4-mapped IPv6 representation, use the separate IPv4-to-IPv6 tool, because converting an integer to dotted-decimal does not create IPv6 connectivity.
Storage and Sorting Across Languages and Databases
| Storage representation | Numeric range | Ordering behavior |
|---|---|---|
| Signed 32-bit integer | -2,147,483,648 to 2,147,483,647 | Numeric; high values appear negative |
| Unsigned 32-bit integer | 0 to 4,294,967,295 | Numeric; covers full IPv4 range |
| Wider integer (64-bit) | Far exceeds IPv4 | Numeric; safest against overflow |
| Decimal string | 0 to 4,294,967,295 as text | Lexicographic; "10" sorts before "9" |
| Dotted-decimal string | Four 0-255 numbers as text | Lexicographic; does not sort by network order |
For production migrations, compare a sample of converted values against a maintained IP-address library in the destination language — Python's ipaddress.IPv4Address is documented at docs.python.org — and verify database column boundaries before bulk conversion. Keep the original dotted-decimal string alongside the integer when auditability matters, and document which representation your code expects so future readers do not have to reverse-engineer the choice.
The conversion is also useful for binary protocol notes, test fixtures, firewall exports, spreadsheets, and any system that sorts or compares addresses numerically. Private, loopback, multicast, documentation, reserved, and public addresses all convert with the same arithmetic, so a high decimal value is not by itself evidence that an address is routable, assigned, or appropriate for an access-control rule. Apply current address registries and network policy separately when classification matters.
For a deeper look, see Xbox Series S IPv4 to IPv6: A Practical Walkthrough.