NetCalcLab

IP to Decimal Converter

Convert an IPv4 address to its 32-bit unsigned decimal integer. This is the form geolocation databases, firewall engines and log analysers store addresses in.

Enter a dotted-decimal address.

Examples:

The address is already a number

Dotted-decimal notation is a presentation format, not the underlying data. An IPv4 address has always been a single 32-bit integer — the dots are inserted every eight bits so humans can read it. Converting to decimal simply removes that presentation layer.

Weighted sum
Decimal = a × 256³ + b × 256² + c × 256¹ + d × 256⁰
        = a × 16,777,216 + b × 65,536 + c × 256 + d

192.168.1.1 -> 192 × 16,777,216 = 3,221,225,472
               168 ×     65,536 =    11,010,048
                 1 ×        256 =           256
                 1 ×          1 =             1
                                  -----------
                                  3,232,235,777

The powers of 256 come from the octet size: shifting a byte one position to the left multiplies its value by 256, exactly as shifting a decimal digit one position to the left multiplies by 10.

Why the conversion is not always safe

The integer form is convenient, but the type you store it in matters enormously. Values from 128.0.0.0 upward set the most significant bit, and a signed 32-bit integer interprets that bit as a sign. Half the IPv4 address space is therefore negative if you use the wrong type.

Example: the signed-integer bug

192.168.1.1 has the top bit set, so a signed 32-bit int holds it as 3,232,235,777 − 4,294,967,296 = -1,061,515,519. Code that stores this in a signed int column and compares it against a positive constant will silently fail to match, while the same code works fine for addresses below 128.0.0.0 — which is why these bugs often survive testing on a private 10.x network.

JavaScript has a related trap: all bitwise operators coerce their operands to signed 32-bit integers. The fix is to normalise the result with >>> 0, which reinterprets it as unsigned. That is exactly what this site's engine does on every IPv4 result.

Where decimal addresses show up

  • Geolocation and WHOIS APIs. The classic GeoIP database keys on an integer range, so converting an address to its integer form is the first step in a lookup.
  • Server logs and analytics. Many high-volume log pipelines store addresses as integers to keep indexes small and range scans fast.
  • Firewall and ACL engines. Rules expressed as integer ranges compile to a handful of comparisons instead of a set of string patterns.
  • Browsers and HTML. The deprecated host form of a URL accepted a bare decimal, so http://3232235777/ resolved to 192.168.1.1. This still works in some clients and is a known filter-bypass technique.

Common mistakes

  • Using a signed 32-bit type. Half the address space appears negative, and comparisons and range queries break.
  • Reversing the octet weights. The first octet carries 256³, not 256⁰. Reversing gives a consistent but wrong number for every address.
  • Multiplying by 1000 instead of 256. Treating the dotted form as plain decimal digits loses the byte alignment and produces a value that is not an IPv4 address at all.
  • Forgetting that the maximum is 4,294,967,295. Values above that indicate either an IPv6 address or an error, not a large IPv4 address.

Also: Decimal to IP Converter · IP to Binary Converter · IP to Hex Converter · Hex to IP Converter · Binary to IP Converter

Reference: addresses as integers

Well-known IPv4 addresses and their decimal and hex values
AddressDecimalHexNotes
0.0.0.0000000000Smallest possible value
0.0.0.1100000001Second smallest value
1.1.1.116,843,00901010101Reads as a repeated hex pattern
8.8.8.8134,744,07208080808Public DNS resolver
10.0.0.0167,772,1600A000000Start of RFC 1918 10/8
10.0.0.1167,772,1610A000001First host in 10/8
127.0.0.12,130,706,4337F000001Loopback
172.16.0.02,886,729,728AC100000Start of RFC 1918 172.16/12
192.168.0.03,232,235,520C0A80000Start of RFC 1918 192.168/16
192.168.1.13,232,235,777C0A80101Common home gateway
223.255.255.2553,758,096,383DFFFFFFFTop of the unicast range
224.0.0.03,758,096,384E0000000Start of multicast
255.255.255.2554,294,967,295FFFFFFFFLargest possible value

The private ranges are contiguous integer ranges too: 10.0.0.0/8 is 167,772,160 to 184,549,375, and 192.168.0.0/16 is 3,232,235,520 to 3,232,301,055. Range checks against those two numbers are how address classification is implemented in most databases.

Reverse direction: decimal to IP. Related: IP to binary, IP to hex, full IP converter.

Frequently asked questions

How do I convert an IP address to a decimal number?

Treat the 32 bits as a single unsigned binary number and evaluate it. For 192.168.1.1 that is 192 × 16,777,216 + 168 × 65,536 + 1 × 256 + 1 = 3,232,235,777. Each octet is weighted by a power of 256 according to its position.

Why are the weights 16,777,216 and 65,536?

Because each octet is eight bits, and moving one octet to the left shifts the value by eight bit positions, which multiplies it by 2^8 = 256. So the weights are 256^3 = 16,777,216 for the first octet, 256^2 = 65,536 for the second, 256 for the third and 1 for the fourth.

What is the largest possible decimal IPv4 value?

4,294,967,295, which corresponds to 255.255.255.255. It is 2^32 − 1, the largest value that fits in 32 unsigned bits. Any decimal value above that cannot be an IPv4 address.

Why do databases store IP addresses as integers?

Integer storage is four bytes instead of up to 15 characters, comparisons become single machine instructions rather than string comparisons, and range queries reduce to BETWEEN start AND end. Sorting is also correct numerically, which it is not for the dotted string form — as text, 10.0.0.1 sorts before 9.0.0.1.

Why does my conversion produce a negative number?

Because the code used a signed 32-bit integer. Values from 128.0.0.0 upward have the top bit set, and in a signed type that bit means negative. A signed int will show 192.168.1.1 as -1,061,515,519 instead of 3,232,235,777. Use an unsigned type or a 64-bit integer and the problem disappears — this converter uses unsigned arithmetic throughout.

How do I convert the decimal value back to an address?

Divide by 16,777,216 and take the integer part for the first octet, then work down through the remaining remainders using 65,536, 256 and 1. The decimal to IP converter does this automatically and shows each octet.