CruxDevCruxDev Tools Prompts
network Utility • Zero-Server Privacy • 100% Client-Side

IPv4 Address Converter

Convert IPv4 addresses between dotted decimal, hexadecimal, binary, octal, and integer representations.

Overview

Converts a dotted-decimal IPv4 address into its unsigned 32-bit integer, hexadecimal, binary and octal representations as you type, with one-click copy on every field. Useful wherever addresses appear as integers - database columns, ip2long-style functions, access-control configs and packet documentation.

How It Works

Type an IPv4 address; the default 192.168.1.1 shows the format. Four cards appear once the input parses: the integer value, the 0x-prefixed hexadecimal form, the binary form written as four eight-bit groups separated by dots, and the octal form with a leading zero per octet. Click any card to copy its value. Invalid input - too many octets, values above 255, non-numeric parts - simply hides the results rather than showing a wrong number.

Step-by-Step Usage Guide

  1. Type the address in dotted-decimal form. Results appear only when all four octets parse and fall within 0-255.
  2. Click the Integer card to copy the unsigned 32-bit value for use in databases or ip2long-equivalent code.
  3. Click Hex for the 0x-prefixed form used in packet dumps and low-level configs, or Binary to read the bit layout against a subnet mask.
  4. Use Octal for legacy Unix contexts where inet_aton-style parsing still applies.

Technical Specifications & Standards

An IPv4 address is a 32-bit number that dotted decimal merely paints four ways, and this tool does the arithmetic in the unsigned domain: each octet is shifted into position with unsigned coercion, so the result is a true integer from 0 to 4,294,967,295 rather than a signed value. The coercion matters because JavaScript bitwise operations are 32-bit signed, and without it 192.168.1.1 would come out negative. The binary card shows each octet padded to eight bits, which is how subnet masks are best read bit by bit. The octal form uses the C-style leading-zero convention (0300.0250.0001.0001 for 192.168.1.1), which is worth knowing about because several Unix networking tools in the inet_aton family still accept it - and because a leading zero in some modern contexts means a different base entirely, so treat octal output as tool-specific. Validation requires exactly four numeric octets in 0-255; anything else leaves the cards hidden. The conversion is pure arithmetic on strings: no lookup, no network, no stored state.

Targeted Use Cases

  • Converting an address to its integer form for storage or comparison in databases that store IPs as BIGINT.
  • Reading the bit pattern of a subnet mask in binary to see exactly which bits are network and which are host.
  • Cross-checking the output of inet_addr, ip2long or similar functions against a known-correct conversion.
  • Decoding an integer found in a log or config back into its dotted-decimal meaning by working through the octets.

Notes & Gotchas

  • Store IPv4 as a 32-bit integer in databases when you index or range-query it; use this tool to sanity-check the conversion both ways.
  • Be careful with octal in config files: a leading zero that looks decorative may make a parser read the octet in base 8.
  • Remember the integer is unsigned; a signed 32-bit read of values above 2,147,483,647 will show negative numbers.
  • Validate input on your own side too - this tool hides results for malformed octets, but your code should reject them explicitly.

Frequently Asked Questions

Why is my integer conversion negative in my own code?

You are reading the 32-bit result as signed. JavaScript bitwise operations operate on signed 32-bit integers, and this tool compensates with an unsigned coercion; in other languages use an unsigned type or mask with 0xFFFFFFFF to match the values shown here.

Does the tool support IPv6?

No. This converter is scoped to dotted-decimal IPv4 and its 32-bit representations. IPv6 addresses are 128-bit and need a different representation strategy altogether.

Why does the octal output have leading zeros?

That is the conventional C notation for octal, which legacy inet_aton-family parsers accept. The tool writes each octet with a leading 0 so the form is unambiguous about its base - and so you can spot it when a config parser surprises you with base interpretation.

What happens with an invalid address?

The results simply do not render. The parser requires exactly four numeric octets between 0 and 255, and anything else - missing octets, out-of-range values, stray characters - leaves the input as-is without showing a misleading number.