IP to Hex Converter
and What 0x7F000001 Is Hiding
Convert an IPv4 or IPv6 address to hexadecimal in every notation a browser will accept, or convert hex back. A whole column at once if you need it. Then use the third tab for the thing most converters skip: paste a link you do not trust and see the real host behind it — including the @ trick that makes a URL look like it points at somewhere safe.
Paste a column of addresses — IPv4, IPv6 or hex, mixed is fine. Each line is worked out on its own and the direction is decided per line.
| Input | Hex | Type |
|---|
Nothing is fetched and nothing is sent anywhere — the URL is only taken apart, here in your browser. Opening the link is still your call, and still a bad idea if you do not trust it.
Quick Answer: How Do You Convert an IP to Hex?
Turn each octet into two hex digits and join them. 127.0.0.1 becomes 0x7F000001. Browsers accept that form in a URL, which is exactly why it turns up in phishing links — and why the third tab decodes them back.
Robert Harrison
OSINT & Network Utility Expert
Robert works on network diagnostics and the practical end of IP tooling — the conversions, lookups and calculations that sit underneath everything else.
Most pages that convert an IP address to hex explain the use case from one side. One of the better-known ones says outright that you can use it to bypass somebody else's IP checkers. That is true, and it is the smaller half of who actually needs this.
The larger half is whoever just got sent http://0x2EE5E0C2/verify and wants to know what it is. So the third tab takes a whole URL apart instead of an address — it handles the @ sign, defanged hxxp:// links, and every numeric host format a browser will follow. Same arithmetic, pointed the other way.
Last reviewed 24 August 2026 · Runs entirely in your browser · No link is ever fetched or logged
View all articles by Robert HarrisonWhere Do You Actually Meet a Hex IP Address?
Hexadecimal is base-16, and it is how computers show bytes to people. Each hex digit covers exactly four bits — a nibble — so two digits are one octet and a whole IPv4 address fits in eight characters. That compactness is the reason it turns up in three very different places.
In packet captures and memory
Open a capture in Wireshark or a core dump in a debugger and addresses appear as raw bytes. 7F 00 00 01 in a header is 127.0.0.1, and being able to read that without reaching for a calculator is a working skill. Nothing suspicious here — this is just what the wire looks like.
Byte order matters more than the notation
The same address has two hex forms depending on where you are reading it. 192.168.1.1 is C0A80101 on the wire, because network byte order is big-endian by definition. In the memory of an x86 machine the same four bytes sit the other way round, as 0101A8C0.
Get that backwards while building a struct or reading a dump and you do not get an error — you get 1.1.168.192, a perfectly valid address that is not the one you wanted. The little-endian toggle above flips it, which is the option most converters leave out.
In firewall and embedded configuration
Some ACL syntaxes, a lot of embedded code and most low-level network programming prefer hex because bitwise operations are easier to reason about in it. A subnet mask written 0xFFFFFF00 tells you at a glance that the top three bytes are fixed and the last is free; the same mask as 255.255.255.0 takes a moment longer to read that way. For the mask arithmetic itself rather than the notation, the subnet calculator is the page.
In links that would rather you did not read them
This is the one worth spending time on. http://0x7F000001/ resolves exactly as http://127.0.0.1/ does, in every mainstream browser, today. It is not a bug and it has not been patched out. RFC 3986 section 7.4 acknowledges the problem directly, noting that additional address formats are a security consideration.
Two things stop being true once a host is written in hex. A person skimming a link has nothing familiar to judge — 0x2EE5E0C2 reads as noise rather than as an address. And tooling that extracts a domain and checks it against a threat feed frequently extracts nothing usable, so the link is never checked at all. Mandiant made exactly that point in its write-up of the technique: a defence tool that checks a domain against a threat feed can be bypassed entirely, because common URL parsing logic fails and fails silently.
IPv6 belongs in this section too, for a reason that trips people up: it is already hexadecimal, so "converting" it sounds meaningless. The useful output is the flat thirty-two-character form — 2001:db8::1 as 20010DB8000000000000000000000001 — which is what a VARBINARY(16) column or a packet buffer wants, and what you cannot get by deleting colons from a compressed address by hand.
To convert the same address to a plain integer instead, the IP to decimal converter covers that notation and why databases use it And to put a whole column of addresses into numeric order, the IP sorter does that. For the fully expanded IPv6 form on its own, the IPv6 expansion tool is the page.
How Many Ways Can One Address Be Written?
More than most people expect, and a browser will follow all of them. Here is 127.0.0.1 written eight ways, every one of which reaches the same place:
| Notation | 127.0.0.1 written that way | Where you see it |
|---|---|---|
| Dotted decimal | 127.0.0.1 | Everywhere normal |
| Hex, single value | 0x7F000001 | Phishing links, filter bypass |
| Hex, dotted | 7F.00.00.01 | Packet captures, configs |
| Hex, dotted with prefixes | 0x7F.0x00.0x00.0x01 | Bypass payloads |
| Decimal dword | 2130706433 | Databases, shortened links |
| Octal | 0177.0.0.1 | Filter bypass, old scripts |
| Fewer than four parts | 127.1 | Shorthand, and it still works |
| Mixed bases | 0177.0x0.0.1 | Deliberate obfuscation only |
Why mixing bases works at all
Because the parsing rule is older than the web. A numeric host is split on dots into up to four parts, and each part is read independently: 0x means hexadecimal, a leading zero means octal, anything else is decimal. With fewer than four parts, the last one absorbs whatever bytes are left — which is why 127.1, 127.0.1 and 2130706433 all land on the same address.
That behaviour comes from inet_aton, and browsers inherited it. It means a single address has a very large number of valid spellings, and a filter comparing strings sees all of them as different.
This is a documented filter-bypass technique, not a theoretical one. Current web application firewall research lists alternative address formats alongside case tricks and null bytes: octal 0177.0.0.1, dword 2130706433, hex 0x7F000001. A rule that blocks the string 127.0.0.1 stops none of them. The fix is to normalise the host to its canonical form before comparing, never to compare the text as typed.
That matters most in SSRF filters. The whole point of one is to stop a server being talked into fetching from itself, and 0x7F000001, 0177.0.0.1 and 2130706433 are all ways of saying 127.0.0.1 to a server while saying nothing recognisable to a naive filter.
Octal deserves its own mention because it produced one of the more memorable real examples — and it has its own page here, because leading zeros turn out to be a security topic in their own right. A phishing mail reported to the Unicode mailing list wrote its host in mathematical bold digits; read as octal, 05671360302 resolves to 46.229.224.194. It worked in Firefox and Chrome. Two layers of disguise on one hostname, and neither of them broke anything.
How Do You Read a Link That Is Hiding Its Host?
Two tricks do most of the work, and they are usually combined.
The @ sign
Everything before an @ in the authority part of a URL is login information, not a destination. So in http://google.com@0x7F000001/ the host is 0x7F000001, and google.com is a username that gets thrown away. The link reads as Google to anyone skimming it, and goes somewhere else entirely.
Mandiant documented this shape distributing several malware families, tracking it as URL Schema Obfuscation and finding it in use since at least February 2022. The illustration everyone quotes — hxxp://google.com@1157586937 — is worth being accurate about: it came from a tweet demonstrating the trick and it opens a Rick Roll, not malware. It resolves to 68.255.95.249.
It gets quoted because it stacks both techniques in one line. The userinfo field misleads the reader; the dword host misleads the parser. Neither needs the other, and together they defeat a person and a tool at the same time.
The numeric host
Once the reader is past the @, the host itself is written in a base they will not decode by eye. Hex is the most common because it is compact; octal shows up because it survives filters; plain dword shows up because it does not even look like an address.
Reading one by hand: find the last @ inside the authority — the host is everything after it, up to the next /, ? or #. Strip any :port. Whatever is left is the real destination, and if it is numeric in any base, the decoder above will turn it back into a dotted address. Then judge that address, not the link.
Doing it in code
If you are normalising hosts in a filter or a log pipeline rather than reading one by hand, both standard libraries already implement the full inet_aton rule:
The rule underneath both is the same one this page keeps coming back to: canonicalise first, compare second. A blocklist checked against raw user input is not a blocklist.
Numeric hosts are only one branch of URL deception. The Punycode converter handles the other big one, where a domain uses characters that look like Latin letters but are not, and the URL encoder and decoder unpicks percent-encoding used to hide the path. If the link resolves to a real domain and you want to know where it eventually lands, the redirect checker follows the chain.
What this page cannot tell you
It decodes notation. That is a smaller claim than it sounds and worth being precise about.
Obfuscated does not mean malicious
Penetration testers, researchers and cross-browser test suites all use these forms legitimately. A hex host is a signal that somebody chose to make the destination hard to read, not proof of intent.
Nothing is fetched
The URL is taken apart as text in your browser. No request is made to it, so nothing here tells you what is actually being served, and pasting a link is not the same as visiting one.
A domain stays a domain
If the host is a name rather than a number there is nothing to decode. The page tells you that plainly rather than guessing — resolving the name is a different job.
Browsers do not all agree
Parsing follows the classic inet_aton rule, which is what browsers have historically implemented, but individual builds vary at the edges. Treat a decoded host as very likely rather than certain.
Once you have the real address, a geolocation and network lookup tells you who it belongs to, and a blacklist check tells you whether anyone has reported it.
To see the same address as bits instead, the binary converter lays out all thirty-two.
Frequently asked questions about hexadecimal IP addresses
How do I convert an IP address to hexadecimal?
Convert each octet to two hex digits and join them. 127.0.0.1 becomes 7F, 00, 00, 01 — written together as 0x7F000001, or dotted as 7F.00.00.01. Each hex digit covers four bits, so two digits are exactly one octet. The converter above shows every accepted format at once because they are not interchangeable in every context.
What is 0x7f000001?
It is 127.0.0.1 — localhost — written as a single hexadecimal number. You will meet it in three places: shortened URLs designed not to look like an IP address, filter-bypass payloads, and packet captures. ping 0x7f000001 works from a normal command line on Linux, macOS and Windows, which is the quickest way to prove to yourself that these forms are real.
Do browsers still accept hexadecimal IP addresses in URLs?
Yes. http://0x7F000001/ resolves the same as http://127.0.0.1/, and the same is true for octal and plain decimal forms. This is not a legacy quirk that has been patched out — it is documented behaviour, still current, and RFC 3986 section 7.4 explicitly flags additional address formats as a security consideration.
Why do phishing links use hex IP addresses?
Because the destination stops looking like an address. A user scanning http://0x2EE5E0C2/login has nothing familiar to judge, and automated tooling that extracts a domain and checks it against a threat feed often extracts nothing useful at all. Mandiant documented malware families combining this with the @ trick, producing links that appear to point at a well-known domain while resolving somewhere else entirely.
What does the @ sign do in a URL?
Everything before it is treated as login information, not as the destination. In http://google.com@0x7F000001/ the host is 0x7F000001 and google.com is just a discarded username. It reads as a Google link to anyone skimming. Paste any URL into the third tab above and the real host is extracted for you.
Is a hex IP address dangerous by itself?
No. It is a legitimate notation with ordinary uses — packet captures, memory dumps, embedded work and firewall configuration all show addresses in hex. What matters is context. Hex in a debugger is unremarkable; hex in a link somebody emailed you is a deliberate choice to make the destination hard to read, and that choice is worth reacting to.
Can hex IPs bypass a firewall, WAF or SSRF filter?
They can bypass any filter that pattern-matches dotted decimal instead of resolving the host, which is common enough to appear in current WAF-bypass research alongside octal and dword forms. It matters most in SSRF protection: a filter meant to stop a server fetching from itself is defeated by 0x7F000001, 0177.0.0.1 or 2130706433, all of which reach 127.0.0.1 while looking nothing like it. Normalise the host to its canonical form first, then compare.
What is the hex value for common IP addresses?
127.0.0.1 is 0x7F000001. 8.8.8.8 is 0x08080808. 192.168.1.1 is 0xC0A80101. 0.0.0.0 is 0x00000000 and 255.255.255.255 is 0xFFFFFFFF, which is the largest an IPv4 address can be.
Does this work for IPv6?
Yes, and the useful part is not what people expect. IPv6 is already written in hexadecimal — the groups between the colons are hex — so converting it further sounds pointless. What you actually want is the flat 32-character form: 2001:db8::1 becomes 20010DB8000000000000000000000001. That is what goes into a VARBINARY(16) column, a packet buffer or a firmware constant, and it is what this page gives you alongside the expanded address.
What does the little-endian option do?
It reverses the byte order. 192.168.1.1 is C0A80101 big-endian, which is how it travels on the wire — network byte order is big-endian by definition. An x86 host stores that same value in memory as 0101A8C0. If you are reading a memory dump or building a struct rather than reading a packet, that reversal is the difference between the right address and a nonsense one.
Can I convert a list of addresses at once?
Yes. The list tab takes up to a thousand lines — IPv4, IPv6 and hex mixed together, direction decided per line. The output options apply to the whole list, so you can produce a column of lowercase colon-separated hex in one pass. Results copy as tab-separated text or download as CSV.
Related tools
Other notations, and the rest of the URL-deception family.
Browse the full set on the TrustMyIP tools directory.
Last updated 24 August 2026 · Runs in your browser · No link is fetched or logged