Paste a host, an IPv4 or IPv6 address, or a full URL. The tool extracts the host, decodes every alternate encoding an attacker can use to slip an address past a naive SSRF filter, and classifies the canonical address as loopback, private, link local, CGNAT, reserved, or public.
A naive defense against server side request forgery keeps a list of forbidden strings, blocks 127.0.0.1 and maybe localhost, and considers the job done. The trouble is that the loopback address has dozens of valid spellings. The same 32 bits can be written as a single decimal number, as octal, as hexadecimal, with some octets in one base and some in another, or wrapped inside an IPv6 form. Many URL parsers and network libraries happily accept all of those and resolve them to the same destination, so a filter that only matches the dotted decimal string lets every other form straight through. This tool draws on the address text rules in RFC 3986 and the special purpose registries described in RFC 6890.
When the host is an IPv4 address, or decodes to one, the tool computes the full set of equivalent forms from the same 32-bit integer, using BigInt for the math so nothing overflows:
127.0.0.1 form.2130706433.0177.0.0.01, where a leading zero switches an octet to base eight.0x7f.0x0.0x0.0x1, and the dotless hex form 0x7f000001.::ffff:127.0.0.1 and its hex form ::ffff:7f00:1.The tool also accepts these encodings as input. Paste a dotless decimal, an octal, a hex, or a mapped IPv6 form and it decodes back to the canonical dotted quad, then classifies that.
Once the address is canonical, the tool checks it against a fixed table of special ranges and gives a plain verdict:
127.0.0.0/8 block, not just 127.0.0.1.10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.169.254.0.0/16, with the cloud metadata address 169.254.169.254 called out on its own as high risk.100.64.0.0/10.0.0.0.0/8, multicast 224.0.0.0/4, the benchmarking and documentation ranges, and the broadcast address.The address 169.254.169.254 sits in the link local range and is the instance metadata endpoint on several cloud platforms. A server side request that reaches it can return instance credentials and configuration, which is why it earns its own warning. An attacker who finds an SSRF and a filter that misses an alternate encoding of this address often turns a small bug into a full credential leak. For the wider shape of these attacks, the AI security testing approach reasons about how a request flows end to end rather than matching one string.
This tool runs in a browser page and a browser page cannot perform DNS resolution, so it works on literal addresses and on the host it pulls out of a URL. It does not look up names. A complete SSRF defense has to handle the name layer too, including DNS rebinding, where a hostname resolves to a harmless public address when the filter checks it and to an internal address a moment later when the server actually connects. Treat the encodings and the range verdict here as one slice of the problem, the slice you can compute offline with certainty, and pair it with server side resolution and revalidation after redirects. The same readable surface and parser disagreement themes run through web application security more broadly.
The top card shows the canonical dotted quad and a one line verdict on the range it falls in. Below it, the encodings panel lists every equivalent spelling so you can confirm your own filter against each one, and a short note restates the core idea: all of the forms above resolve to the same address, so a blocklist that only matches the literal string misses every other form. The point is not to grade your address, it is to make the bypass surface visible. For the broader set of trust boundaries attackers probe, see the access control writing.