One address, many spellings
An IP address is a number. Everything else — the dots, the colons, the hexadecimal — is
notation, and notation is a human convenience that software does not share. 8.8.8.8,
134744072, 0x08080808 and
00001000.00001000.00001000.00001000 are the same 32 bits written four ways. A machine
that stores addresses as integers, a firewall that logs them in hex and a spreadsheet that has
helpfully turned them into numbers are all talking about the same thing.
That is the whole purpose of this page: take whatever form you have and show every other form, in both directions. Paste an address and get the number; paste the number and get the address back. The page never sends anything anywhere — the conversion happens in JavaScript in the tab you are looking at.
The forms, and when each one turns up
- Decimal
- The address as a single integer. This is what databases store when a column is
INT UNSIGNEDrather than a string, because integers compare and sort correctly while strings put10.0.0.2after10.0.0.10. It is also whatinet_aton()and its equivalents return. If a log or an export has given you a bare nine- or ten-digit number where an address should be, this is why. - Hexadecimal
- Two hex digits per octet for IPv4, thirty-two digits for IPv6. Packet dumps, kernel messages
and
/proc/net/tcpon Linux all speak hex — and/proc/net/tcpwrites it byte-reversed on little-endian machines, which is a well-known way to lose an hour. - Binary
- The form worth looking at exactly once, when subnetting stops making sense. Seeing where a
/26boundary falls inside the third octet turns prefix arithmetic from a memorised table into something obvious. - Octal
- Shown here as a warning rather than a convenience — see the section below.
- IPv6 expanded and compressed
- The same IPv6 address written in full (
2001:0db8:0000:0000:0000:0000:0000:0001) and canonically (2001:db8::1). The compressed form follows RFC 5952: lowercase, no leading zeros, and::replacing the longest run of zero groups. Software that compares addresses as text rather than as numbers will treat those two strings as different, which is why access lists and allow-lists should be built from parsed addresses, never from string equality. - IPv4-mapped IPv6
::ffff:8.8.8.8. A socket opened as IPv6 but talking to an IPv4 peer reports the remote address in this form, which is why an IPv4 address suddenly appears in your logs wearing colons. If your allow-list only matches dotted quads, it will not match this — a genuine and common source of "the rule works locally and not in production".- 6to4 prefix
- The
2002::/16block that embeds an IPv4 address in bits 16–47. The transition mechanism itself was deprecated in 2015 and the public relays are gone, but the notation survives in old configurations and in traffic from hosts nobody has revisited. - Reverse DNS zone
- The name a PTR record actually lives at:
8.8.8.8.in-addr.arpafor IPv4, and for IPv6 thirty-two nibbles in reverse order underip6.arpa. Writing that IPv6 name by hand is how zone files acquire typos, and the typo does not produce an error — it produces a lookup that silently returns nothing.
Why the octal form is on this page at all
A leading zero in an octet is not decoration. The classic C function
inet_aton() — and everything historically built on it, which includes a great deal of
still-running software — reads an octet beginning with 0 as an octal
number. Under that rule 010.1.1.1 is 8.1.1.1. Modern parsers, including
Python's ipaddress module and Go's net/netip, reject the leading zero
outright instead. A third group accepts it and reads it as decimal.
So the same string can mean two different addresses, or no address at all, depending on which
library sees it. That is not a curiosity; it is a security primitive. If a validator reads
010.1.1.1 as "10.1.1.1, that's fine" and the HTTP client that runs afterwards reads it
as 8.1.1.1, the check and the connection have gone to different places — which is
precisely the shape of a server-side request forgery bypass. The same trick appears in blocklist
evasion, where an entry is written in a form the blocklist does not recognise but the resolver
does.
We show you the octal form so that you recognise it when you meet it, and we read a leading zero as decimal while saying so out loud. The practical rule is short: never write a leading zero in an address, and when validating addresses from outside, parse them into a number and compare numbers — never compare the strings.
Reading a number back into an address
Paste a bare integer and the page converts in the other direction. Numbers below
4 294 967 296 are read as IPv4, because that is what someone typing a number into an IP converter
almost always means; anything larger is read as IPv6. A 0x prefix is understood, and
so is a string of exactly 32 or 128 binary digits.
The ambiguity is real and we would rather name it than hide it: 1 is
0.0.0.1 under the IPv4 reading and ::1 under the IPv6 one. Both are
legitimate; the page picks IPv4 and tells you so under the field, instead of guessing quietly and
letting you find out later.
Nothing here reaches us
The whole conversion runs in your browser. There is no form that submits, no request in the background and no entry in our logs — we do not know which addresses you looked at. If you would rather verify that than take our word for it: load the page, disconnect the network, and keep using it.