An IPv4 address is a 32-bit number wearing decimal clothes
Dotted-decimal notation — four numbers 0–255 separated by periods — is a human-readability convention layered on top of what an IPv4 address actually is: one plain 32-bit unsigned integer. Each of the four "octets" is simply one byte of that 32-bit value, displayed in decimal rather than hex purely because that's the convention IPv4 settled on in the 1980s. Converting an address to hex reveals the same four bytes without the dot-separated decimal formatting — 192.168.1.1 and0xC0A80101 are the exact same 32 bits, read two different ways.
Why some tools and logs prefer the hex form
Low-level networking tools, packet analyzers, and routing tables frequently display or store addresses in hex specifically because hex maps directly onto byte boundaries the way decimal doesn't — reading a raw packet header hex dump and identifying the four address bytes is direct byte-pair reading, with no decimal conversion needed at all. Some systems also store IP addresses as a single 32-bit integer internally (in a database column, for instance) for compact storage and fast range comparisons, and hex is often how that integer is inspected or debugged when something needs to be checked by hand rather than by additional tooling.
Byte order matters here too
Converting 0xC0A80101 to 192.168.1.1 assumes the bytes are read in the order they'd naturally be written — most significant byte first, matching how the address is conventionally displayed. If a 32-bit integer representing an IP address has been stored or transmitted in little-endian byte order (common when an address is packed into a struct on an x86 system without explicit byte-order conversion), the raw bytes need to be reversed before this straightforward hex-to-dotted-decimal mapping applies — otherwise the octets come out in the wrong order entirely. This is exactly the same byte-order concern covered on the Little Endian Hex ↔ Decimal page, applied specifically to 4-byte address values instead of general integers.
Why this tool doesn't cover IPv6
IPv6 addresses are 128 bits rather than 32, conventionally written as eight groups of four hex digits separated by colons (with a shorthand for consecutive zero groups) — meaning an IPv6 address is already displayed in hex by default, unlike IPv4's decimal convention. Converting IPv6 to and from hex is much less useful as a distinct tool because there's no decimal intermediary step to bridge, the way IPv4's dotted-decimal notation requires; the address is effectively already in the format this tool would otherwise produce.
A worked conversion
Take 0xC0A80101. Split into four byte pairs: C0, A8,01, 01. Converting each independently from hex to decimal —C0 is (12 × 16) + 0 = 192; A8 is (10 × 16) + 8 = 168; the remaining two pairs are both simply 1 — gives 192, 168, 1, 1, joined with periods: 192.168.1.1, a private-network address from the reserved 192.168.0.0/16 block commonly used for home and small-office routers. Each byte pair converts completely independently of the others, the same way plain hex-to-RGB conversion works — there's no cross-byte arithmetic involved anywhere in the process.
Private address ranges worth recognizing in hex
A few IPv4 ranges are reserved for private networks and show up constantly in local network configuration: 10.0.0.0/8 (hex prefix 0x0A), 172.16.0.0/12 (hex prefix starting0xAC1 through 0xAC1F), and 192.168.0.0/16 (hex prefix 0xC0A8). Recognizing these hex prefixes at a glance is occasionally useful when scanning a hex dump of network configuration or packet data and trying to quickly tell whether an embedded address is a private, internal one or a public, routable one, without converting every value back to dotted-decimal first.
Working with address ranges and lists
A common practical use for hex IP conversion is reviewing firewall rules, access logs, or IP allowlists that mix hex and dotted-decimal notation, or performing basic range arithmetic (subnet boundaries, address counts) that's easier to reason about as a single 32-bit integer than as four separate decimal octets. Batch mode below lets a full list of addresses be converted in either direction at once, useful for normalizing a log file or configuration list to one consistent notation.