IP to Decimal Converter

Convert an IPv4 address to its 32-bit decimal integer, hex, and binary representations.

IPv4 Address

Decimal (uint32)3232235777

Hexadecimal0xC0A80101

Binary (octets)11000000.10101000.00000001.00000001

Dotted-quad192.168.1.1

Quick examples

How IPv4 address conversion works

Every IPv4 address is a 32-bit unsigned integer written in dotted-quad notation for human readability. This converter shows the raw uint32 decimal value, the hex representation (used in network configs and firewall rules), and the 8-bit-per-octet binary breakdown. The decimal form is what protocols like IP headers store internally — for example, 192.168.1.1 is 3232235777.

To convert in the other direction, use the Decimal to IP Converter. For subnet calculations, see the IP Subnet Calculator.

Built and maintained by Meet Shah · Last updated 30 July 2026

What this tool is used for

Producing the integer form of an address for a database column or a range comparison.
Checking a subnet boundary by looking at the integer and binary forms together.
Converting an address for an API that expects a numeric value.
Building range checks where integer comparison is cheaper than string parsing.
Confirming your own conversion code against a known value.

Frequently Asked Questions

What is the formula?: Multiply out each octet: (a × 16777216) + (b × 65536) + (c × 256) + d. Equivalently, treat the four bytes as one big-endian 32-bit integer — which is exactly how the address travels on the wire.
What are the boundary values?: 0.0.0.0 is 0 and 255.255.255.255 is 4294967295 — the full unsigned 32-bit range, which is why IPv4 has about 4.3 billion addresses in total. Recognising 4294967295 as all-ones is a useful debugging cue.
How does this help with subnet maths?: Enormously. Once addresses are integers, a CIDR block is a contiguous range, so membership is one comparison and the block size is 2^(32−prefix). Doing the same on dotted quads requires per-octet masking.
How do private ranges appear in decimal?: 10.0.0.0/8 is 167772160-184549375, 172.16.0.0/12 is 2886729728-2887778303, and 192.168.0.0/16 is 3232235520-3232301055. Firewall rules stored as integers are checked against exactly these bounds.
Is byte order relevant?: Yes, at the network layer. Addresses travel big-endian (network byte order), so code on a little-endian machine must convert with htonl/ntohl — omitting it produces a reversed and wildly wrong address.
Why do the octets use powers of 256?: Because each octet is eight bits, so the leftmost carries 2^24, then 2^16, 2^8 and 1. It is ordinary positional notation in base 256, which is why the arithmetic is a weighted sum rather than concatenation.
What happens if an octet exceeds 255?: The value overflows into the next octet's range, producing a different address entirely. That is why validation must precede conversion — `1.2.3.300` has no valid integer form, but a naive sum still returns a number.

Common errors and gotchas

Getting the octet order wrong, which yields a valid-looking integer for a different address.
Storing the value as signed, which makes anything above 127.255.255.255 negative.
Assuming the technique extends to IPv6, which needs 128 bits and does not fit an integer column.
Comparing an integer address against a masked value without applying the same mask to both.
Treating leading zeros in an octet as octal, which some parsers do and which changes the address.