IP to Decimal Explained: Turning 192.168.1.1 Into a Single 32-Bit Integer

An IPv4 address looks like four small numbers glued together with dots: 192.168.1.1. It reads like four things. Under the hood it is exactly one thing — a 32-bit unsigned integer. The dots are punctuation we added so humans can read it. Drop the punctuation and 192.168.1.1 is the number 3232235777, full stop.

That single fact quietly powers a lot of infrastructure. Databases store it. Firewalls compare it. Geo-IP lookups depend on it. Once you can move between the dotted form and the integer form in your head (or with a tool), a chunk of networking stops being mysterious. Let me walk through the actual math, a worked example you can check by hand, and why the integer form is worth caring about.

Four octets, four 8-bit chunks

The word for each of those four numbers is an octet — eight bits. Eight bits hold values from 0 to 255, which is why no octet can ever be 256 or higher. Four octets stacked together give you 4 × 8 = 32 bits, and 32 bits hold values from 0 up to 4,294,967,295.

So the whole address is one 32-bit slot, carved into four byte-sized windows:

11000000 . 10101000 . 00000001 . 00000001
   192        168          1          1

The leftmost octet is the most significant byte. It sits at the top of the 32-bit number and carries the most weight. The rightmost octet is the least significant — it changes the value by the smallest amount. This is exactly like reading a normal decimal number left to right, except each position is worth 256 times the one to its right instead of 10 times.

The packing formula

Here is the one concrete rule that makes everything else fall out. To turn a dotted address into its integer, multiply each octet by a power of 256 based on its position, then sum:

integer = octet1 × 256³ + octet2 × 256² + octet3 × 256¹ + octet4 × 256⁰

Those powers of 256 are just the byte positions. The first octet is shifted up by three bytes (256³ = 16,777,216), the second by two (256² = 65,536), the third by one (256), and the last by zero (× 1). Big-endian, top to bottom.

Worked example: 192.168.1.1

Let's prove 192.168.1.1 = 3232235777 by hand. Plug each octet into the formula:

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

Add the four lines and you get 3,232,235,777. No rounding, no approximation — it is an exact, reversible mapping. Every legal IPv4 address corresponds to exactly one integer in the 0 to 4,294,967,295 range, and every integer in that range maps back to exactly one address.

You can check this yourself in the IP to Decimal Converter: type 192.168.1.1 and it shows 3232235777, the binary 11000000.10101000.00000001.00000001, and the hex 0xC0A80101 side by side, each with a copy button. The hex is the same number written base 16, which networking gear often prefers because each pair of hex digits is exactly one octet — C0 is 192, A8 is 168, and so on.

Going backwards: integer to IP

The reverse is just the formula run in the other direction. Take an integer, peel off four bytes from most significant to least:

3,232,235,777 ÷ 16,777,216 = 192, remainder 11,010,305
   11,010,305 ÷ 65,536     = 168, remainder        257
          257 ÷ 256        =   1, remainder          1
            1              =   1

Read the quotients top to bottom — 192, 168, 1, 1 — and you have your address back. This is the single most useful trick when a log line or an API response hands you a bare number like 3232235777 with zero context. Paste it into the number-to-IP side of the tool and the host name reveals itself instantly.

Why store an IP as an integer at all

This is where the math pays rent. Three places lean on it constantly.

Database storage and indexing. A 15-character VARCHAR for 255.255.255.255 is bigger and slower to index than a single 32-bit (or 64-bit) integer column. Convert the address once at write time, store the integer, and only convert back for display. Smaller index, faster lookups.

Range comparison. A whole subnet is a contiguous block of integers, so a range query is trivial. To count every hit from 10.0.0.0/8, convert the network address 10.0.0.0 and the broadcast 10.255.255.255 to integers and run WHERE ip BETWEEN 167772160 AND 184549375. No CIDR arithmetic living inside your SQL — just two plain numbers as bounds.

Geo-IP lookups. Geo-IP databases are tables of integer ranges, each mapped to a country or city. The lookup is a single "which range does this integer fall into" query, which an integer index answers far faster than any string comparison ever could.

When I was building a request-logging table for a small service, I made the rookie mistake of storing source IPs as strings first. The subnet-range reports I wanted later turned into ugly string-prefix matching that missed edge cases. I rebuilt the column as an unsigned integer, converted everything through the integer form, and the BETWEEN queries became one clean line that actually returned the right rows. The conversion step I had skipped at the start was the whole point.

The traps worth knowing

A few things bite people, and they all come straight from the bit layout:

Byte order. The first octet is the most significant byte. 1.2.3.4 is 16909060, not 67305985. Build the integer little-endian by accident and every address comes out wrong.
Signed overflow. 255.255.255.255 is 4294967295, larger than the 2147483647 ceiling of a signed 32-bit int. Use an unsigned 32-bit or a 64-bit column, or every address above 127.x wraps to a negative number.
Leading zeros. 192.168.01.1 looks harmless, but some parsers read 01 as octal and silently change the value. Strip the zero — an octet is plain decimal 0 to 255.

If you want to see why the binary view makes subnetting obvious — how a /24 mask is 24 ones then 8 zeros, and where the network/host boundary sits — the base converter lets you flip the same number between decimal, binary, and hex and watch the bits line up. The dotted-binary output is the same idea, just pre-split into octets so the boundaries jump out.

Takeaway

An IPv4 address is one 32-bit integer wearing four dots as a costume. Each octet is an 8-bit chunk weighted by a power of 256: first octet × 256³, then 256², then 256, then × 1, summed. 192.168.1.1 packs to 3232235777, and the same math unpacks it back. Store the integer, compare ranges with it, look up geo data with it — and convert at the edges only when a human needs to read it.

Made by Toolora · Updated 2026-06-13