IP Address Converter — Dotted Decimal, Integer, Hex & Binary

Background.

This IP address converter takes one IPv4 address and rewrites it in every notation the address can legally wear: dotted decimal, a single unsigned 32-bit integer, hexadecimal, binary, and the zero-prefixed octal form that POSIX inet_addr() accepts. It also derives three things that fall out of the same 32 bits — the legacy class letter, the IPv4-mapped IPv6 address, and the in-addr.arpa reverse-DNS name. The notation selector works in both directions: paste 3232235777 and pick '32-bit integer' and you get 192.168.1.1 back, along with every other form.

The reason this is a calculator rather than a fact is that an IPv4 address is not really four numbers. RFC 791 §2.3 is blunt about it: "Addresses are fixed length of four octets (32 bits)." The dots are a human convenience layered on top of a single 32-bit integer, and the four-part written form only got a formal grammar much later, in the RFC 3986 §3.2.2 ABNF that bounds each dec-octet at 255. Everything on this page is that one integer, viewed through a different base.

The integer form is the one people actually come here for. If you have ever stored addresses in a database, you have met it: an INT UNSIGNED column holds an IPv4 address in four bytes instead of the fifteen characters a VARCHAR would need, and — far more importantly — it makes range queries work. GeoIP tables, abuse blocklists and CDN allowlists are all published as integer ranges precisely because BETWEEN on an integer is an index seek, while string comparison on '192.168.1.9' versus '192.168.1.10' sorts the wrong way round. MySQL exposes the same conversion as INET_ATON()/INET_NTOA(), PostgreSQL as a cast on the inet type, and Python as int(ipaddress.IPv4Address(...)).

The binary view earns its place for a different reason: subnet masks only make sense in binary. A /26 is 26 leading ones, and seeing 192.168.1.1 as 11000000.10101000.00000001.00000001 is what makes it obvious which bits the mask keeps. Hexadecimal is what you read in a packet capture, because two hex digits map exactly to one octet with no arithmetic in between.

The octal output exists as a warning. POSIX specifies that the parts of a dotted address "may be decimal, octal, or hexadecimal, as specified in the ISO C standard", so inet_addr("192.168.010.1") is 192.168.8.1, not 192.168.10.1. Modern parsers in Go, Python 3.9.5+ and Rust reject leading zeros outright; C, PHP and many embedded stacks still read them as octal. Because the two answers disagree, this converter refuses a dotted address with a leading zero rather than guessing, and tells you to use the octal mode if octal is what you meant.

Below the widget you will find the octet arithmetic written out, a note on why this page uses exact decimal arithmetic instead of JavaScript's bitwise operators (they silently produce negative numbers above 2,147,483,647), the classful history and why RFC 4632 deprecated it, and how the reverse-DNS and IPv4-mapped IPv6 forms are built. This page converts one bare address; for prefixes, masks, network and broadcast addresses use the IP subnet calculator and the CIDR-to-netmask converter linked below.

What is ip address converter?

An IPv4 address is a 32-bit unsigned integer that identifies an interface on an IP network. RFC 791, the 1981 specification of the Internet Protocol, defines it as four octets — 32 bits — and nothing in the protocol itself says anything about dots. The dotted-decimal notation everyone writes (192.168.1.1) is a convention for humans: split the 32 bits into four 8-bit groups, print each group in decimal, and separate them with full stops. Because 8 bits can hold 0 through 255, each of the four numbers is bounded at 255, which is exactly what the RFC 3986 §3.2.2 ABNF encodes with its `dec-octet` rule.

Once you accept that the address is one number, converting it is just a change of base. The integer value is o0 x 16,777,216 + o1 x 65,536 + o2 x 256 + o3, so 192.168.1.1 is 3,221,225,472 + 11,010,048 + 256 + 1 = 3,232,235,777. Writing that number in base 16 gives 0xC0A80101 (two hex digits per octet); in base 2 it gives 11000000.10101000.00000001.00000001; in base 8, octet by octet with a leading zero, it gives 0300.0250.01.01.

Three derived forms come from the same bits. The legacy class letter is read off the leading bits of the first octet — RFC 791 defines class A as leading bit 0, class B as 10, class C as 110, with D (multicast) and E (reserved) added later. The IPv4-mapped IPv6 address places the 32 bits after 80 zero bits and a 16-bit FFFF field, written ::ffff:192.168.1.1 under the RFC 4291 §2.2 mixed notation. The reverse-DNS name reverses the octets and appends in-addr.arpa, so 10.2.0.52 becomes 52.0.2.10.in-addr.arpa — RFC 1035 §3.5 admits the reversal is "awkward to read" but explains it "allows zones to be delegated which are exactly one network of address space".

How to use this calculator.

1. 01Choose the notation you are starting from. 'Dotted decimal' is the everyday form (192.168.1.1); '32-bit integer' is the single number a database or GeoIP table stores; 'Hexadecimal' is what you read in a packet capture; 'Binary' is the 32-bit view you need for subnet masks.
2. 02Type or paste the address into the field. Do not include a /nn prefix — this page converts one address. If you need network and broadcast addresses, use the IP subnet calculator linked in the related tools.
3. 03Read the dotted-decimal result first: whatever notation you started from, this is the canonical form. Every other output is the same 32 bits in a different base.
4. 04Use the 32-bit integer when you need to store or range-query addresses. It is the value MySQL's INET_ATON() returns and the value an INT UNSIGNED column holds in four bytes.
5. 05Use the binary output when you are working out a subnet by hand. Count the leading bits your mask keeps and everything to the right is host space.
6. 06Use the reverse-DNS name when you are creating or debugging a PTR record — that is the exact name a resolver queries when it reverse-looks-up the address.
7. 07Hexadecimal may be entered with or without the 0x prefix and shorter than eight digits: 0xFFFF is read as 0.0.255.255. Binary may be entered with or without dots between the octets, but must be exactly 32 bits.

The formula.

Forward conversion (dotted decimal to integer) is positional notation in base 256:

value = ((o₀ × 256 + o₁) × 256 + o₂) × 256 + o₃ = o₀ × 16,777,216 + o₁ × 65,536 + o₂ × 256 + o₃

For 10.20.30.40: 10 × 16,777,216 = 167,772,160; 20 × 65,536 = 1,310,720; 30 × 256 = 7,680; plus 40. The sum is 169,090,600.

Reverse conversion (integer to dotted decimal) divides back out:

o₀ = ⌊value / 16,777,216⌋ mod 256 o₁ = ⌊value / 65,536⌋ mod 256 o₂ = ⌊value / 256⌋ mod 256 o₃ = value mod 256

Hexadecimal is the same integer in base 16, zero-padded to eight digits, and because 16² = 256 each octet maps to exactly two hex digits with no carrying between them: 10 → 0A, 20 → 14, 30 → 1E, 40 → 28, giving 0x0A141E28. Binary is base 2 per octet, zero-padded to eight bits: 00001010.00010100.00011110.00101000. Octal is base 8 per octet with a leading zero — note that the octal form is not fixed width, so octet 1 prints as 01 and octet 192 prints as 0300.

One implementation note that matters more than it looks. JavaScript's bitwise operators (&, |, >>>, <<) coerce their operands to *signed* 32-bit integers, so the perfectly ordinary address 192.168.1.1 — value 3,232,235,777, above 2³¹ − 1 = 2,147,483,647 — comes back as −1,062,731,519 the moment you touch it with a bitwise operator. This calculator uses no bitwise operators at all. Every step is exact integer arithmetic (floor-divide, multiply, modulo) in Decimal.js, so addresses in the upper half of the space behave identically to addresses in the lower half. If you are writing this conversion yourself in JavaScript, use multiplication and division, or the unsigned shift >>> 0 to correct the sign afterwards.

The class lookup is a pure range test on the first octet: 0–127 class A, 128–191 class B, 192–223 class C, 224–239 class D (multicast), 240–255 class E (reserved). RFC 791 §2.3 defines A, B and C by their leading bits — 0, 10 and 110 — and D and E were added by later documents. RFC 4632 chose to "deprecate the Class A/B/C network address assignment system in favor of using 'classless', hierarchical blocks of IP addresses (referred to as prefixes)", so this output is a historical lookup only; nothing in modern routing consults it.

A worked example.

Frequently asked questions.

References& sources.

1. [1]Postel, J. (ed.) (1981). RFC 791, Internet Protocol — DARPA Internet Program Protocol Specification, §2.3 Function Description and §3.2 Discussion. "Addresses are fixed length of four octets (32 bits)." The same section defines the classful split by leading bits: "in class a, the high order bit is zero … in class b, the high order two bits are one-zero … in class c, the high order three bits are one-one-zero". Source for the 32-bit width and the legacy class output.
2. [2]Berners-Lee, T., Fielding, R. & Masinter, L. (2005). RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, §3.2.2 Host. Gives the formal ABNF for dotted-decimal notation — IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet — with dec-octet bounded at "25" %x30-35, i.e. 0–255. Source for the per-octet range this calculator enforces.
3. [3]IEEE and The Open Group (2018). IEEE Std 1003.1-2017 (POSIX.1-2017), System Interfaces: inet_addr(). Specifies the a.b.c.d, a.b.c, a.b and a forms, and states that "All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal, as specified in the ISO C standard". Source for the octal output and for rejecting leading zeros in dotted input.
4. [4]Hinden, R. & Deering, S. (2006). RFC 4291, IP Version 6 Addressing Architecture, §2.2 Text Representation of Addresses and §2.5.5.2 IPv4-Mapped IPv6 Address. Defines the 80-zero-bits + FFFF + IPv4 layout and the mixed textual form x:x:x:x:x:x:d.d.d.d, with the example ::FFFF:129.144.52.38. Source for the IPv4-mapped IPv6 output.
5. [5]Mockapetris, P. (1987). RFC 1035, Domain Names — Implementation and Specification, §3.5 IN-ADDR.ARPA domain. "Thus data for Internet address 10.2.0.52 is located at domain name 52.0.2.10.IN-ADDR.ARPA"; "The reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space." Source for the reverse-DNS output.
6. [6]Fuller, V. & Li, T. (2006). RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, §2 and §3.1. Records the decision to "deprecate the Class A/B/C network address assignment system in favor of using 'classless', hierarchical blocks of IP addresses (referred to as prefixes)". Source for labelling the class output as legacy.