IP lookUp IP lookUp

IP Address Format Converter

Type an IPv4 address, its 32-bit decimal integer, its dotted-binary form, or its hexadecimal form, and this converter instantly shows the same address in all four notations — computed entirely in your browser, with nothing ever sent to a server.

IP Address Format Converter

An IPv4 address is a single 32-bit number; dotted-decimal notation (192.168.1.1) is just the most common of several ways to write that number, chosen because it's easy for a person to read. Split into its 4 octets, each 0–255, and packed most-significant-octet-first, the same address is also a plain 32-bit integer, a run of 32 binary digits, or 8 hexadecimal digits — and every one of those forms shows up somewhere in real systems. This page is for a developer parsing a value out of a log line, a database column or a config file, who needs to go from whatever form the system handed them back to a normal address (or the reverse), without writing throwaway conversion code for a one-off lookup.

Decimal integers show up most often as a compact storage format: MySQL/MariaDB's INET_ATON()/INET_NTOA() pair stores an IPv4 column as a 4-byte unsigned integer instead of a 15-character string, and plenty of legacy log formats and access-control tables do the same for indexing speed. 192.168.1.1 becomes 3232235777 the same way this page computes it: (192 × 256³) + (168 × 256²) + (1 × 256) + 1. A common bug when hand-rolling this conversion is treating an octet with a leading zero as octal instead of decimal — some parsers historically read 192.168.010.1 as octet 8 (010 in base 8), not 10 — so a converter that silently "fixes" ambiguous input is worse than one that just rejects it; this page requires strict, unambiguous decimal octets on the IP-address tab.

Hexadecimal shows up in packet captures, some proxy/firewall logs, and URLs that embed an address as a hex literal (browsers still accept http://0xC0A80101/ as a valid, if unusual, way to write http://192.168.1.1/). Binary — always shown here as 4 dot-separated 8-bit groups, matching how a netmask or wildcard mask is usually written — is mostly useful for seeing exactly which bits differ between two addresses, or for cross-checking a subnet boundary by eye instead of trusting arithmetic alone. All four forms describe the same 32 bits; this page never guesses which form you meant beyond the tab you have selected, and every invalid entry is reported as a plain error rather than silently coerced into the nearest valid value.

Glossary

Dotted-decimal notation
The familiar 4-octet form (192.168.1.1) — each of the 4 groups is one byte of the address, written as a decimal number 0–255, separated by dots.
32-bit integer form
The same address packed into one unsigned integer 0–4294967295, most-significant octet first — the form used by database functions like MySQL's INET_ATON() and many legacy log/index formats.
Byte order (network order)
The convention that the first octet written (leftmost) is the most significant byte of the integer — "network byte order" or big-endian. Reading bytes in the opposite order silently produces a completely different, still-valid-looking address.
Hexadecimal (hex) form
The 32-bit integer written in base 16 (0xC0A80101), 8 hex digits — one nibble per 4 bits — often seen in packet dumps and some proxy/firewall logs.
Dotted-binary form
The address written as 4 groups of 8 binary digits (11000000.10101000.00000001.00000001), matching how a netmask or wildcard mask is conventionally displayed.
Leading-zero ambiguity
Some legacy parsers treat an octet written with a leading zero (010) as octal rather than decimal, silently reading it as 8 instead of 10 — a real source of address-parsing bugs across different libraries and languages.

Frequently asked questions

Why does 192.168.1.1 equal 3232235777 as a decimal integer?
Because that's the same 32 bits, just read as one number instead of 4 separate bytes: (192 × 256³) + (168 × 256²) + (1 × 256) + 1 = 3232235777. This is exactly what MySQL/MariaDB's INET_ATON() function computes when you store an IPv4 address as an integer column.
Does this converter accept IPv6 addresses?
No — this page is IPv4-only decimal/binary/hex conversion. IPv6's own compact and expanded notations are a different task, covered by the IPv6 subnet calculator instead.
Why did my binary input get rejected?
The binary tab needs exactly 32 binary digits — either as 4 dot-separated groups of 8 (11000000.10101000.00000001.00000001) or as one continuous 32-character run of 0s and 1s; anything with a different digit count, or a character other than 0/1, is reported as invalid rather than guessed at.
Why does 192.168.010.1 not convert the way I expect?
Some libraries historically interpret a leading zero as an octal prefix, so 010 becomes 8 instead of 10 — a real, documented source of address-parsing inconsistency between tools. This converter requires plain decimal octets on the IP-address tab and does not guess at an octal reading.
Does this tool send my IP address anywhere?
No. Every conversion on this page runs entirely in your browser using plain arithmetic; nothing you type here is sent to our servers or anywhere else.
What's the largest value the decimal tab accepts?
4294967295 (2³² − 1), which converts to 255.255.255.255 — the highest possible IPv4 address. Anything above that, or a negative number, is rejected as out of range.

API equivalent

The conversions above run entirely on your device — this page makes zero network requests to compute any result on it. If you'd rather resolve a real, routable IP address server-side as part of a larger lookup (not just reformat it), our main API returns full network/RDAP facts for it:

curl 
curl "https://ip.xakki.pro/api/v1/ip?ip=192.168.1.1&include=network"

Example response (trimmed):

{
  "schemaVersion": 15,
  "status": "ok",
  "ip": "192.168.1.1",
  "version": 4,
  "flags": {
    "isPrivate": true
  }
}

Read the full API docs

Like this tool? Our API gives free accounts 1,000 requests/day.See the API docs →