IPv4 ↔ Integer Converter — moving an address between dotted-quad, decimal, hex, and binary

A practical look at the PortJar IPv4 ↔ Integer Converter — when database columns, packed protocols, or hex dumps make you read an address as a 32-bit number instead of dotted-quad.

Most of the time an IPv4 address is just four numbers separated by dots. Then a billing analyst opens a database table where someone stored addresses as an INT(10) UNSIGNED, or a packet capture surfaces a header field in hex, or a Splunk dashboard insists on showing addresses as 32-bit decimals — and suddenly nobody at the table can read the number on the screen. The PortJar IPv4 ↔ Integer Converter is the small tool that turns those numbers back into something a human can match against a firewall rule.

What the tool does

It converts an IPv4 address between four representations: the familiar dotted-quad (192.168.10.42), an unsigned 32-bit decimal (3232238122), hex (0xC0A80A2A), and binary (11000000.10101000.00001010.00101010). It accepts any of those forms on input — the tool detects which representation you typed and produces the other three. The math runs entirely in the browser; nothing is logged.

The decimal form follows the convention used by INET_ATON in MySQL and inet_aton(3) in libc: the high-order byte of the dotted-quad becomes the most significant byte of the integer. That is the same convention used by Splunk, ClickHouse, BigQuery, and almost every analytics tool that stores IPs compactly. If a database elsewhere uses the opposite byte order, you’ll notice immediately — the converter’s output won’t match.

How to use it

Open portjar.com/tools/ip-converter and paste whichever representation you have. If you paste 192.168.10.42, you get the decimal, hex, and binary forms back. If you paste 3232238122, you get the dotted-quad. The tool does not require you to specify which form you typed; it sniffs the input.

The hex form is shown with and without the 0x prefix so you can copy whichever shape your downstream tool expects. The binary form is grouped into the four octets so it lines up with the dotted-quad — useful when you’re walking through a netmask alongside the address.

When you’d reach for it

  • Database forensics. A reporting query against a users table groups by last_login_ip stored as INT UNSIGNED. Before anyone can act on the report, you need the human-readable address.
  • Log normalisation. A SIEM or analytics tool exports IPs as decimals to save bytes. Converting one or two suspicious entries by hand confirms whether the alert is about your office, a customer, or a known bad actor.
  • Reading a pcap or hex dump. Wireshark normally formats addresses for you, but raw protocol decoders, embedded debug traces, and custom binary formats often don’t. The converter turns C0 A8 0A 2A into 192.168.10.42 in one paste.
  • Working with bitwise ops in code. When you’re writing a function that checks whether an address falls inside a CIDR, you almost always end up holding the address as an integer. The converter gives you the test data in the form your code actually consumes.
  • Verifying an obfuscated URL. A phishing message uses http://3232238122/ as the host. Converting the decimal exposes that it’s actually 192.168.10.42, which is private space — a strong signal the link is malformed or actively malicious.

What to make of the output

The four representations are mathematically equivalent. If the dotted-quad you started with produces the decimal you expected, you can trust the hex and binary too — they are mechanical transformations of the same 32-bit number. There is no rounding, no precision loss, and no place where a 16-bit truncation could sneak in.

The most common reason an analytics dashboard shows an unexpected decimal value is that the data pipeline upstream wrote the bytes in the opposite order (sometimes called “network byte order” reversed in error). If the converter’s decimal doesn’t match the database value, the database column wasn’t populated by INET_ATON — it was populated by something else, and you need to look at the ingest code, not the converter.

A blank result for one of the fields means the input wasn’t a valid IPv4. Quadruple-check: a stray comma in a CSV import, a zero at the start of an octet that some parsers interpret as octal, or an IPv6 address pasted into an IPv4 field are the common causes.

For environments where IP data flows between databases, logs, and runtime firewall rules — and has to round-trip cleanly — Stack Harbor enforces the conversion discipline as part of environment management.

Book consult