IP Address Converter — decimal, binary, hex, IPv6

The IP address converter above takes an address in any common representation and shows every other representation of the same value: dotted decimal, a single unsigned integer, binary, hexadecimal, the IPv4-mapped IPv6 form, the fully expanded and correctly compressed IPv6 forms, and the reverse-DNS name used for PTR lookups. It runs as local JavaScript in your browser, with no lookup, no geolocation and no network request of any kind.

Arb Digital publishes this alongside its other free developer and networking tools because addresses turn up in different shapes depending on where you are standing. A database column stores an integer, a packet capture shows hexadecimal, a firewall rule shows dotted decimal, and a log from a dual-stack service shows an IPv4 address wearing an IPv6 prefix. Being able to move between them quickly saves a surprising amount of time during an investigation.

What This IP Address Converter Does

An IPv4 address is not really four numbers. It is a single 32-bit unsigned integer that is conventionally written as four 8-bit pieces separated by dots because that is easier for humans to read. The address 192.168.1.1 and the number 3,232,235,777 are the same value, and so is 0xC0A80101, and so is the 32-bit binary string 11000000101010000000000100000001. This tool moves between all of those without changing anything.

IPv6 works the same way at a larger scale: 128 bits, written as eight groups of four hexadecimal digits, with a range of shorthand rules for suppressing zeros. The tool expands any IPv6 address to its full form, produces the canonical compressed form, and gives the 128-bit integer for anyone who needs to store or sort addresses numerically.

Boundary worth stating: this page converts one address between representations. If you need network and broadcast addresses, host counts, or CIDR arithmetic, that is the job of the IP subnet calculator, which takes a prefix length and works out the range. Nothing here involves a mask.

How to Use It

1. Paste any representation. Detection handles dotted decimal, integers, hexadecimal with or without the 0x prefix, binary, and every IPv6 form.
2. Force the interpretation if the value is ambiguous. A string of ones and zeros is both a valid decimal number and a valid binary address; the selector settles it.
3. Read the integer for storage. It is what you want in a database column that has to sort or range-query on address.
4. Read the IPv6 forms for dual-stack work. The mapped form is what an IPv4 client looks like when it reaches an IPv6 socket.
5. Copy the reverse-DNS name for PTR record work. It is generated in the correct reversed-nibble order for IPv6, which is tedious to write by hand.

How the Conversion Works

For IPv4, each dotted octet is multiplied by a power of 256 and summed: the address a.b.c.d becomes a×16,777,216 + b×65,536 + c×256 + d. Take 192.168.1.1. That is 192×16,777,216 = 3,221,225,472, plus 168×65,536 = 11,010,048, plus 1×256 = 256, plus 1, giving 3,232,235,777. In hexadecimal each octet is simply two hex digits, so 192 becomes C0, 168 becomes A8, 1 becomes 01 and 1 becomes 01, producing 0xC0A80101. Reversing the process uses integer division and remainders by the same powers of 256. RFC 791, the Internet Protocol specification, defines the address as a fixed length of four octets.

For IPv6 the same idea runs over 128 bits, which exceeds what a JavaScript number can hold exactly, so the tool uses arbitrary-precision integers to avoid the silent rounding that would otherwise corrupt the low-order bits. The compression rules matter here: a run of consecutive all-zero groups may be replaced by a double colon, but only once in an address, and RFC 5952, A Recommendation for IPv6 Address Text Representation, tightens that further by requiring lowercase hexadecimal, suppression of leading zeros in each group, and compression of the longest zero run — the first such run when two are equally long. The tool follows those rules, so its output is the canonical form that comparisons and log deduplication expect.

The IPv4-mapped IPv6 form comes from RFC 4291, the IP Version 6 Addressing Architecture, which defines it as eighty zero bits, then sixteen bits of ones, then the 32-bit IPv4 address. That is why an IPv4 client connecting to a dual-stack service appears in logs as ::ffff:192.168.1.1 rather than as a plain IPv4 address.

Why the Integer Form Is Worth Using

Storing addresses as integers rather than strings solves several problems at once. Range queries become simple comparisons, so “is this address inside this block” is a single between clause rather than string manipulation. Sorting produces the correct network order rather than lexicographic nonsense, where 10.0.0.9 sorts after 10.0.0.10 because the character 9 is greater than the character 1. Storage shrinks from up to fifteen bytes of text to four bytes.

Two cautions come with that. First, signedness: a 32-bit signed integer column cannot hold addresses above 127.255.255.255 without wrapping negative, which is why addresses in the 128–255 first-octet range appear as large negative numbers in some legacy systems. Use an unsigned type, or a 64-bit signed one. Second, IPv6 does not fit in any integer type most databases offer, so a 16-byte binary column is the usual answer. Several databases now provide dedicated address types that handle both families and their masks properly, which is preferable to either.

Reading Unusual IPv4 Forms Safely

This is where address parsing becomes a security topic rather than a formatting one. Historically, many libraries accepted variations that are not dotted-quad at all: a bare integer, three parts where the last part covers sixteen bits, and octets written in octal when they carry a leading zero. Under those rules 010.0.0.1 is 8.0.0.1 rather than 10.0.0.1, because the leading zero means octal, and 2130706433 is 127.0.0.1.

That inconsistency has caused real vulnerabilities. A filter that checks a string against a blocklist of internal addresses, and a network stack that later resolves an alternative encoding of the same address, disagree about what the value means, which is one route to a server-side request forgery. The safe pattern is to parse an address into its numeric form once, validate against ranges numerically rather than by string matching, and re-render it in canonical form before passing it anywhere else. This tool always renders canonically, and it treats leading zeros as decimal rather than octal, which is the behaviour modern parsers have standardised on — but it is worth knowing that not every system agrees.

Scopes and Ranges the Converter Flags

Alongside the conversion, the tool reports the scope of the address: whether it falls in the private ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, in the loopback range 127.0.0.0/8, in the link-local range 169.254.0.0/16, in the carrier-grade NAT range 100.64.0.0/10, in multicast space, or in ordinary public space. For IPv6 it distinguishes loopback, link-local, unique local addresses beginning fc00::/7, multicast beginning ff00::/8, the documentation prefix 2001:db8::/32 and global unicast.

That flag answers the practical question quickly: an address in private space in a public-facing log usually means a proxy is not forwarding the client address correctly, and a link-local address means autoconfiguration ran without a router. For the wider workflow, the DNS record generator helps once you have the reverse name, the number base converter covers general base conversion, and the bitwise calculator is useful when you are masking bits by hand.

Common Mistakes to Avoid

• Storing addresses in a signed 32-bit column. Anything above 127.255.255.255 wraps to a negative number and breaks every range comparison you write against it.
• Sorting addresses as strings. Lexicographic order puts 10.0.0.10 before 10.0.0.9. Convert to integers first, or use a native address type.
• Blocklisting addresses by string match. Alternative encodings of the same address defeat it. Parse to a number and compare ranges numerically.
• Assuming leading zeros are decimal everywhere. Some legacy parsers read 010 as octal 8, so canonicalise before comparing values across systems.
• Treating ::ffff:203.0.113.9 as a different client from 203.0.113.9. It is the same IPv4 address arriving on an IPv6 socket, and counting it separately inflates your unique-visitor figures.

Related Free Tools From Arb Digital

For network ranges, masks and host counts, use the IP subnet calculator. The number base converter handles general integer base conversion, the bitwise calculator covers masking and shifting, and the two's complement converter explains signed integer storage. Once you have a reverse name, the DNS record generator builds the record, and the data storage converter handles byte and bit units elsewhere in the stack. Everything else is in the free online tools hub.

Frequently Asked Questions