Decimal to IP Converter

What this tool is used for

• Turning an integer IP stored in a database column back into a readable dotted quad.
• Reading an IP that a log or an API rendered as a single number.
• Checking that an integer conversion in your own code produces the address you expect.
• Converting a stored range boundary back into addresses to sanity-check it.
• Seeing the hex and binary forms alongside, to check a mask or a subnet boundary.

Frequently Asked Questions

How does the conversion work?

A dotted-quad address is a single 32-bit integer: a.b.c.d equals a×2^24 + b×2^16 + c×2^8 + d. So 3232235777 is 192.168.1.1 — the dots are purely a human convenience over one number.

Why would an IP be stored as an integer?

Because it is compact, fast to index, and makes range queries trivial — checking whether an address falls in a subnet becomes a simple integer BETWEEN. That is why geolocation and firewall databases store them this way.

Which datatype should hold it?

An UNSIGNED 32-bit integer, or a 64-bit signed one. A signed 32-bit column overflows above 127.255.255.255 and stores negative values for half the address space — a real and common bug.

Does this work for IPv6?

The same idea, but the number is 128 bits, which exceeds every native integer type. IPv6 needs two 64-bit halves, a decimal string, or a dedicated type such as Postgres INET.

Why do some short forms still resolve?

Because inet_aton accepts partial forms — 127.1 expands to 127.0.0.1, and a bare integer is accepted directly. Browsers historically honoured this, which made it a classic obfuscation and SSRF-filter bypass.

Why does the integer form need to be unsigned?

Because addresses above 127.255.255.255 set the high bit, which a signed 32-bit type reads as negative. Storing them in a signed column is why some addresses come back as negative numbers and fail to convert.

What is this used for in practice?

Range queries. Comparing integers makes `BETWEEN` work for a subnet, which is far faster than string matching — the reason geolocation databases store address ranges as integer pairs.

Common errors and gotchas

• Getting the byte order wrong, which produces a valid-looking address with the octets reversed.
• Treating the integer as signed, so addresses above 127.255.255.255 come out negative or wrap.
• Assuming the value is IPv4 when it is a truncated or packed IPv6 representation.
• Feeding in a value beyond the 32-bit range and getting a silently truncated result.
• Confusing an integer IP with an integer subnet mask, which look identical and mean different things.