An 8-character hexadecimal IPv4 address is the same 32 bits that dotted-decimal notation splits into four decimal octets, written in base-16 rather than as four base-256 components. For example, the hex string C0A80101 represents the same value as 192.168.1.1, because C0 hex equals 192 decimal, A8 hex equals 168 decimal, and each 01 hex value equals 1 decimal. Converting between the two forms therefore requires reading the same 32-bit number in two different notations: a single big-endian hexadecimal string versus four decimal octets separated by periods. The most reliable workflow is a two-step process: first turn the hex string into an unsigned decimal integer, then feed that integer to a converter that produces the four dotted octets. The IP to Decimal Converter handles the second step exactly, within JavaScript's safe-integer range, without performing any DNS lookup, geolocation request, registry query, or external network call.
How a Hex IPv4 Address Is Built
An IPv4 address is defined as four octets, each from 0 through 255, with the first octet occupying the most significant eight bits and the fourth occupying the least significant eight bits. That layout is documented in RFC 791, which describes the Internet Protocol and the 32-bit address structure still used today. The dotted-decimal form shows those four octets as decimal numbers separated by periods. The hexadecimal form shows the same four octets as two-digit base-16 numbers, either run together as an 8-character string or split with separators such as periods, underscores, or colons.
Reading a hex string is the same operation regardless of the separator style. The first two hex digits are the first octet, the next two are the second, the next two the third, and the final two the fourth. Big-endian byte order is implied, so the first octet you read is the most significant one. That is why C0A80101 starts with C0 (192) and not 01 (1), and why the same value would not change if you wrote it as c0a80101, C0.A8.01.01, or C0:A8:01:01.
| Representation | Structure | Accepted characters | Value range | Where you typically see it |
|---|---|---|---|---|
| Hex IPv4 string | Eight hex digits, two per octet, big-endian | 0 to 9 and A to F, case-insensitive | 00000000 to FFFFFFFF | Wireshark columns, registry exports, log files, reverse-DNS zones |
| Unsigned decimal integer | One number, no separators | 0 to 9, no leading zeros | 0 to 4294967295 | Database columns, firewall rules, test fixtures |
| Dotted-decimal IPv4 | Four decimal octets separated by periods | 0 to 9 in each octet, no leading zeros | 0.0.0.0 to 255.255.255.255 | Browser address bars, configuration files, network tools |
The hex and dotted forms hold identical information; only the numeral system changes. The decimal integer form sits between them and is the form most software actually stores when it needs to sort or compare addresses numerically rather than textually.
The Two-Hop Path From Hex to Dotted Decimal
Few mainstream tools combine a hex parser and a dotted-decimal formatter in a single step, so the cleanest workflow is two short hops. First, parse the hex string as one 32-bit unsigned integer. Second, split that integer back into four base-256 octets. Combining the two steps with exact integer arithmetic guarantees that nothing is lost to floating-point rounding and that ambiguous inputs are rejected rather than guessed.
The first hop can be done by hand for small examples. Take C0A80101:
- Identify each hex digit's place value: 16⁷, 16⁶, 16⁵, 16⁴, 16³, 16², 16¹, 16⁰.
- Substitute the digits: (12×16⁷) + (0×16⁶) + (10×16⁵) + (8×16⁴) + (0×16³) + (1×16²) + (0×16¹) + (1×16⁰).
- Evaluate: 3,221,225,472 + 10,485,760 + 524,288 + 256 + 1 = 3,232,235,777.
That number, 3,232,235,777, is the unsigned 32-bit integer representation of the address. It is also the decimal value that the dotted form 192.168.1.1 unfolds from, because 192×256³ + 168×256² + 1×256 + 1 produces the same total. The reverse direction, used in the next section, decomposes 3,232,235,777 by repeated division and remainder to recover each octet.
Convert the Decimal Integer to Dotted Decimal
The second hop is what the IP to Decimal Converter does best. It accepts a single unsigned decimal integer in the range 0 through 4,294,967,295 and produces the matching IPv4 address with no rounding, no octet guessing, and no network requests. The conversion stays inside the browser, so the value never leaves your machine.
- Choose the decimal to IPv4 direction in the IP to Decimal Converter.
- Enter the integer from the first hop. For C0A80101 that value is 3232235777, with no spaces, no thousands separators, no sign, and no leading zeros.
- Convert and compare the displayed result, which should read 192.168.1.1.
- Copy the dotted form and confirm that the destination field or database column can store it as a plain dotted string or, if you need numeric ordering, as an unsigned 32-bit value rather than a signed 32-bit column.
For readers who already have the dotted form and want the inverse direction, the same tool also accepts a strict IPv4 address and returns its unsigned decimal. That reverse workflow is documented in How to Convert a Decimal IP Address to Hexadecimal, where the same exact-arithmetic approach closes the loop back to base-16.
Why Strict Decimal Input Rules Matter
Hex strings look forgiving because every two-digit pair is a valid byte, but the decimal integer that comes out of them is strict. The IP to Decimal Converter enforces that strictness on purpose. Decimal form must contain digits only, must not start with a leading zero except for the literal value 0, and must stay inside the full unsigned 32-bit range. Dotted form must contain exactly four decimal integers separated by periods, with no surrounding spaces, no signs, no omitted octets, and no leading zeros in any octet.
Those rules are not arbitrary. Leading zeros have historically been interpreted inconsistently by software, sometimes as octal. The address 010.0.0.1 could mean decimal ten, decimal eight, or octal eight depending on the parser. Strict decimal notation eliminates that ambiguity, and the tool's matching eight externally checked cases cover both endpoints, loopback, documentation blocks, private space, multicast-range values, and the maximum address, with reverse assertions for every fixture.
If the integer you enter is rejected, the most common cause is a leading zero pasted from a spreadsheet, a stray space, or a negative sign from a signed 32-bit display. Strip those characters and try again. If your data is already in dotted-hex form such as C0.A8.01.01, concatenate the octets into an 8-character string before the first hop so the conversion stays unambiguous.
Storing and Reading the Result Safely
An IPv4 address converted to a decimal integer is just arithmetic, not a network classification. The value tells you nothing about whether the address is private, loopback, multicast, documentation, reserved, or routable on the public internet. Apply current address registries and network policy separately when classification matters.
Be careful when moving results between languages and databases. Some environments expose 32-bit signed integers, so values above 2,147,483,647 appear as negative numbers. The IPv4 maximum of 4,294,967,295 sits almost twice as high as that signed boundary, which means high addresses such as 255.255.255.255 or large documentation blocks round-trip incorrectly through a signed column. Use an unsigned 32-bit type, a wider integer type, or a validated decimal string as appropriate. The Python ipaddress.IPv4Address documentation explains the same caveat in the context of the language's own integer model.
Database ordering also depends on column type. Textual decimals sort lexicographically, so the string "10" sorts before "9" unless the column is normalized to a fixed width. Dotted addresses do not sort by their numeric network order as plain strings, because "10.0.0.1" sorts before "9.0.0.1" alphabetically. The decimal integer is the form that sorts and compares correctly with a single integer column. Preserve the original input when auditability matters, and document the chosen representation so a future reader can reverse the mapping without guesswork.
When You Need a Different Tool Instead
The IP to Decimal Converter handles individual IPv4 addresses and nothing else. A suffix such as /24 is rejected rather than silently ignored. If you need network and broadcast boundaries, host count, or wildcard masks, the right tool is a dedicated subnet calculator rather than an address converter. Working with binary notation instead of hex follows the same two-hop workflow but uses base-2 rather than base-16 in the first hop, and is covered separately for readers who want that exact path.
If your goal is to package an IPv4 address inside an IPv6 surface, the IP to Decimal Converter does not produce IPv6 connectivity. Use the IPv4-to-IPv6 mapping tool when you specifically need an RFC 4291 IPv4-mapped address in mixed, compressed, or fully expanded form. The integer you compute here is just an intermediate value; converting it does not grant IPv6 reachability and does not change how the address is routed on the public internet.
For production migrations, compare a sample against a maintained IP-address library in the destination language before bulk conversion, and verify the database type boundaries with a few high-value fixtures. Eight test fixtures are not a substitute for a migration script, but they do catch the most common boundary mistakes: signed overflow at 2,147,483,648, the maximum address at 4,294,967,295, the minimum at 0, and the loopback value 2,130,706,433.
For a deeper look, see How to Get a MAC Address in CMD for Development.