The arithmetic behind the conversion
An IPv4 address is four bytes. To get the integer, multiply the first octet by 16777216 (256 cubed), the second by 65536, the third by 256, add the fourth and sum the results. For 192.168.1.1 that is 3221225472 + 11010048 + 256 + 1 = 3232235777. Going back is repeated division by 256, keeping the remainders as octets from right to left.
Hexadecimal shows the same structure with no arithmetic: each octet is exactly two hex digits, so 192.168.1.1 is 0xC0A80101 and the dotted hex row reads 0xC0.0xA8.0x01.0x01. Octal needs three digits per octet, 0300.0250.01.01, and binary eight, 11000000.10101000.00000001.00000001. IPv6 works the same way with 128 bits, which is why its decimal form can run to 39 digits and hex is the everyday notation.
What the converter accepts
Dotted IPv4 must have four parts between 0 and 255 with no leading zeros. 010.0.0.1 is rejected because some software reads 010 as octal 8 and some as decimal 10. A bare decimal up to 4294967295 is read as IPv4, as is a hex value from 0x0 to 0xFFFFFFFF and a 32-digit binary string, with or without dots or spaces between the bytes.
Any valid IPv6 text form is accepted, including the compressed :: notation, an embedded dotted IPv4 tail such as ::ffff:192.0.2.1, square brackets and a zone suffix like %eth0. A decimal integer of 11 to 39 digits is treated as a 128-bit IPv6 value. The error message lists these forms whenever the input matches none of them.
- 192.168.1.1, 3232235777, 0xC0A80101 and 11000000101010000000000100000001 all produce the same card.
- A decimal between 4294967296 and 9999999999 is rejected: too large for IPv4 and too short for the IPv6 path.
- A hex value is always read as IPv4. Write an IPv6 address in colon notation instead.
Where the integer form is used
Relational databases are the main reason to need the number. MySQL's INET_ATON and INET_NTOA functions perform exactly this conversion, and schemas without native address types store IPv4 as an unsigned 32-bit column so that a lookup like WHERE ip BETWEEN 167772160 AND 184549375 can use an index. Geolocation and allow-list tables are usually keyed the same way.
Scripting is the other common case. Checking whether an address falls inside a block, computing the next address or counting the hosts in a range is simple integer arithmetic once the dots are gone. For the block calculations themselves, IPv6 range to CIDR does the work on both IPv4 and IPv6 ranges.
Reading obfuscated and odd-looking addresses
URL parsers follow the old inet_aton rules, so a host can be written as a single integer, as hex with a 0x prefix, as octal with a leading zero, or as fewer than four parts. http://0xC0A80101/, http://3232235777/ and http://0300.0250.0.1/ all reach 192.168.1.1. Such links turn up in spam and in malware logs precisely because people do not recognise them as addresses.
Paste the numeric part here and the dotted form appears in the first row. Once you have the real address, IP lookup shows who owns it and where it is registered.
IPv6 input and the 128-bit integer
For an IPv6 address the card shows four rows: the compressed RFC 5952 form, the fully expanded form, the decimal integer and the 32-digit hex value with a 0x prefix. The integer is exact because the converter uses arbitrary-precision arithmetic, so 2001:db8::1 becomes 42540766411282592856903984951653826561 with no rounding.
Databases rarely store IPv6 as a decimal because ordinary integer columns do not hold 128 bits. A 16-byte binary column or a native inet type is the usual choice, and the expanded hex row is what you feed to those. IPv6 expansion produces that form for a whole list at once.