IP Address Converter

Why these conversions matter

An IPv4 address is just a 32-bit number. Humans write it in dotted-decimal because four numbers from 0 to 255 are easier to remember than ten-digit integers. But computers think in binary, network engineers sometimes work in hex, and ACL/route entries occasionally show up as raw integers in logs.

Quick reference for what each format looks like:

Where you'll actually run into these

• Hex shows up in router config files, packet captures, and some firewall rule formats.
• Integer form appears in databases that store IPs as a 4-byte BIGINT (faster range queries than text comparison).
• Binary is essential for understanding subnet masks — you can't really "get" why a /27 has 32 addresses without seeing the host bits in binary.

Where these conversions actually come up

Most days, if I'm looking at an IP address, it's in the familiar four-numbers-separated-by-dots format. But every once in a while I hit a system that stores or displays IPs in a completely different form, and I need to convert to make sense of what I'm seeing. This tool exists because I got tired of building the conversion in my head or firing up a Python REPL for something that should take two seconds.

Integer form (a single 32-bit number)

Some databases and older applications store IPv4 addresses as a single 32-bit integer. Instead of "192.168.1.1", they store 3232235777. That's the same address, just written as one number instead of four. The math is straightforward — you take each octet, multiply the first by 2^24, the second by 2^16, the third by 2^8, and add them all up — but doing it by hand is error-prone.

MySQL specifically has functions called INET_ATON and INET_NTOA that do this conversion, and older network monitoring tools sometimes log IPs this way to save storage space. If you're exporting data from a system that stores IPs as integers and importing it into something that expects dotted-decimal, you need this conversion. I've done it enough times converting log data between MRTG, LibreNMS, and PRTG that having a tool for it saves real time.

Hexadecimal form

Hex representation of IPv4 addresses shows up in low-level networking contexts. Packet captures from Wireshark occasionally display IPs in hex when you're looking at raw packet headers. Some VPN configurations and network appliance CLIs use hex for IP addresses in specific fields. And in code that manipulates IP addresses byte-by-byte, hex is often the natural intermediate representation because each byte is exactly two hex digits.

The conversion is directly derived from the four octets: each octet becomes two hex digits, concatenated left to right. So 192.168.1.1 becomes 0xC0A80101. If you see a hex string that looks like it could be an IP, converting back to dotted-decimal takes a second and can save you from misidentifying a value.

Binary form

This is the format that actually matters when you're thinking about subnetting. A subnet mask like /24 means "the first 24 bits of this address identify the network," and those bits are much easier to reason about when you can see them as ones and zeros. 192.168.1.42 in binary is 11000000.10101000.00000001.00101010. If you AND that with a /24 mask (11111111.11111111.11111111.00000000), you get the network address 192.168.1.0. If you OR it with the inverse mask, you get the broadcast address.

I don't use binary form often for actual work, but when I'm teaching someone how CIDR notation works or debugging a case where a subnet mask isn't behaving as expected, having the binary representation helps make the underlying math visible.

The IPv6 situation

IPv6 has its own set of conversions, and they're slightly different from IPv4. An IPv6 address is 128 bits, presented as eight groups of four hex digits separated by colons — for example, 2001:0db8:85a3:0000:0000:8a2e:0370:7334. There's a standard shortening rule: runs of zero groups can be collapsed with a double colon (::), and leading zeros in each group can be dropped. So the address above simplifies to 2001:db8:85a3::8a2e:370:7334.

The double-colon can appear only once per address (otherwise it would be ambiguous which zeros were being omitted). If an address has multiple runs of zeros, you have to pick one to compress. Most tools pick the longest run; if runs are the same length, they usually pick the leftmost.

IPv6 also has a concept of "compressed" versus "expanded" notation, and different systems accept different forms. Some databases store IPv6 in the fully expanded canonical form; others accept whatever the human wrote. If you're importing IPv6 data across systems, converting to a consistent representation first prevents duplicate entries.

Common places these conversions matter

Logs from firewalls and routers

Cisco routers occasionally log IPs in hex or in a format that mixes hex and decimal. Fortinet firewalls sometimes present addresses in a nonstandard format in specific log types. Palo Alto usually uses dotted-decimal but has some fields (particularly in NAT logs) that display IPs differently. When correlating logs across multiple vendors, you sometimes need to convert to compare.

Database imports and exports

Older applications store IPs as INT columns in SQL databases. If you're pulling data from an application built in the 2000s and importing into a newer system that stores IPs as strings or as INET types, the format has to match. MySQL's INET_ATON and PostgreSQL's inet type handle this differently, and the tool here matches the common representations both accept.

Programming and API integrations

If you're building a tool that reads IPs from one system and writes them to another, and the two systems use different representations, having a fast conversion reference saves debugging time. Many programming languages have libraries that handle this correctly (Python's ipaddress module, Node's ip package), but sometimes you need to check a value quickly without writing code.

Educational and troubleshooting contexts

When I'm explaining subnetting to someone who's newer to networking, seeing the binary representation makes the math tangible in a way that dotted-decimal alone doesn't. "The first three octets are all 1s in the mask" is more concrete when you can see the actual 24 ones followed by 8 zeros.

Related tools you might need

If you're converting IPs because you need to work with a subnet, the Subnet Calculator handles CIDR blocks, network addresses, broadcast addresses, and usable host counts in a single view. If you have a CIDR block and need to expand it to start and end IPs, the CIDR Range Tool does exactly that. And if you're troubleshooting whether a particular IP falls inside a known range, both those tools will tell you.

For looking up who owns an IP, the IP Lookup tool queries geolocation databases and returns the ASN, ISP, country, and general location. For the reverse (finding a hostname for an IP), the Reverse DNS tool queries the PTR record.

Notes on edge cases

Leading zeros in octets

Some systems accept IPs with leading zeros in the octets (like 192.168.001.001), and some don't. The problem is that leading zeros can be interpreted as octal in some parsers, which changes the meaning of the number. 010 as octal is 8 in decimal, so 192.168.1.010 might mean 192.168.1.8 in one interpreter and 192.168.1.10 in another. This is a real bug source when consuming IPs from external systems. This tool doesn't accept leading zeros, matching the strictest interpretation.

Whitespace and formatting

Some sources include trailing whitespace, tabs, or trailing dots in IP strings. The tool trims obvious whitespace but rejects clearly malformed inputs. If your source data has unusual formatting, clean it before conversion.

IPv4-mapped IPv6

An address like ::ffff:192.168.1.1 is a legitimate IPv6 address that embeds an IPv4 address in the low-order bits. It's how dual-stack systems represent an IPv4 client to code that's expecting an IPv6 socket. When you see this format in logs, the actual client IP is the four octets at the end — the ::ffff: prefix is just the encoding.