Inspect & Identify

IP Address Inspector

Paste any IPv4 or IPv6 address, in any spelling, to see its canonical form, the IPv4 address hidden inside it, every special-purpose range it falls in, and whether it is globally reachable. Analysed in your browser.

Tool request · Agent

IP address inspector (canonical form, special-purpose ranges, embedded IPv4)

Asked for on October 15, 2026. Who asked is never published. Request a tool

CIDR membership

Keyboard shortcuts

Esc
Close a menu or overlay, then leave full screen
↓ on a menu
Open it; ↑ ↓ move through its items
← → in the menu bar
Move between menus

Where your data goes

Using this pageUsing the API, MCP or A2A
Where it runsIn your browser. The address is analysed by this page in your browser; nothing is sent, and the address is neither resolved nor contacted.In a Cloudflare Pages Function at the Cloudflare data centre nearest the caller.
What leaves your deviceNothing you enter. After the page and its scripts load, no request carries your input. The browser enforces this: the page's Content-Security-Policy sets connect-src 'none' and form-action 'none', which block fetch, XHR, WebSocket, EventSource, beacons and form posts.

The server receives the address (and any CIDRs), analyses it in memory, and returns the result. Your input is not stored or logged; only the per-call metadata row (operation, time, status, sizes) is recorded. The address is never resolved or contacted.

StoredNothing leaves the page. No cookies, analytics or third-party scripts; the browser keeps only your View → Inline config choice.Your inputs and results: never. What is stored is your client record (client ID, a SHA-256 hash of your secret, expiry, and the profile you registered with) and one metadata row per call: operation, time, transport, status, error code, duration, request and response sizes, and country.
LoggedNothing (no requests are made).Only the per-call metadata above, attributed to your client ID. Never parameters, bodies, results, or credentials. Cloudflare, as the host, also processes request metadata (IP address, full URL including the query string, headers) under its own policies, so put inputs in POST bodies.
AccessOpen to anyone.Requires a client ID and secret (how to get one). HTTPS only; TLS terminates at Cloudflare.

Details and how to verify this yourself: Security & privacy.

User guide

The tool sits in a window that works like a desktop app: menus on the top row and the full-screen icon at its right (Esc leaves full screen). The set-up options described below are in Settings → Options…, an overlay. To keep the options in view instead, choose View → Inline config; the page remembers that choice. Help → Keyboard shortcuts… lists the keys.

  1. Paste an address in any spelling: 10.0.0.1, ::ffff:a00:1, [2001:db8::1], fe80::1%eth0, even 0x7f.1. Add a /prefix (192.168.1.77/24) to see the network as well.
  2. Optionally, in Settings → Options…, list CIDRs to test it against (one per line or comma-separated), such as the blocks your firewall or SSRF filter refuses.
  3. Read the cards:
    • Overview: the canonical form (with Copy), the full expanded IPv6 form, any zone ID, the IPv4 address embedded in an IPv6 one, and the integer value. The badge says whether the address is globally reachable.
    • Special-purpose ranges: every IANA registry block the address falls in, including blocks matched by its embedded IPv4 address.
    • Network and CIDR membership, when asked for.
    • Notes: non-standard spellings, deprecated forms, host bits set.

Why it matters. An IP address can be written many ways, and code that checks the text instead of the parsed address gets fooled. ::ffff:a00:1 is 10.0.0.1. 0x7f.1 and 2130706433 are both 127.0.0.1 to a browser or curl. 64:ff9b::a00:1 reaches 10.0.0.1 through a NAT64 gateway. An SSRF filter, firewall rule or allow-list has to judge the address these resolve to; this tool shows it.

Specification

Parsing.

  • IPv6: RFC 4291 §2.2 text forms: up to eight 16-bit hex groups, at most one ::, optionally ending in a dotted IPv4 address. Upper and lower case are accepted. Square brackets ([::1]) are accepted; a port ([::1]:443) is refused. A zone ID after % (RFC 4007 §11) is kept separately and does not change the address.
  • IPv4: a strict dotted quad (four decimal parts 0–255, no leading zeros). The legacy forms that inet_aton(3) and the WHATWG URL parser (browsers, curl) accept are also read the way those parsers read them, with a note: one to four parts, each decimal, octal (leading 0) or hex (0x), the last part filling the remaining bytes (127.1, 0177.0.0.1, 0x7f000001, 2130706433). A leading zero means octal there (010.0.0.1 is 8.0.0.1); strict parsers reject such addresses or read them as decimal. One trailing dot is ignored, as URL parsers ignore it.
  • Up to 100 characters. A /prefix (0–32 or 0–128) may follow the address.

Canonical form. IPv4: dotted decimal. IPv6: RFC 5952: lowercase hex, no leading zeros, the longest run of two or more zero groups replaced by :: (the first if two runs are equally long; a single zero group is never compressed). The last 32 bits are written as a dotted IPv4 address for IPv4-mapped, IPv4-compatible and IPv4-translated addresses (RFC 5952 §5) and for the well-known NAT64 prefix 64:ff9b::/96 (RFC 6052 §2.4). ::2 stays ::2 rather than ::0.0.0.2. expanded always has eight four-digit groups; integer is the unsigned value in decimal.

Embedded IPv4. The IPv4 address carried in an IPv6 address, and how:

embeddingBlockWhere the IPv4 address isDefined in
ipv4-mapped::ffff:0:0/96last 32 bitsRFC 4291 §2.5.5.2
ipv4-compatible::/96 (not ::, ::1)last 32 bitsRFC 4291 §2.5.5.1 (deprecated)
ipv4-translated::ffff:0:0:0/96last 32 bitsRFC 2765 (obsolete SIIT)
nat6464:ff9b::/96last 32 bitsRFC 6052
nat6464:ff9b:1::/48bits 48–63 and 72–87 (the /48 layout)RFC 8215, RFC 6052 §2.2
6to42002::/16bits 16–47RFC 3056
teredo2001::/32the client’s address, inverted, in the last 32 bitsRFC 4380

For Teredo, the server address (bits 32–63) and the client’s UDP port are given in the notes.

Ranges. Every block the address falls in, least specific first, from the IANA IPv4 and IPv6 Special-Purpose Address Registries (RFC 6890, updated by RFC 8190) with their columns: source, destination, forwardable, globally_reachable and reserved_by_protocol (null where the registry says N/A). Multicast (224.0.0.0/4, RFC 5771; ff00::/8) and the deprecated site-local block (fec0::/10, RFC 3879) come from the address-space registries and have no columns. A block matched by the embedded IPv4 address has via: "embedded_ipv4".

Global reachability.

  1. The most specific special-purpose block with a value decides (RFC 8190 §3): 192.0.0.9 is reachable although 192.0.0.0/24 is not.
  2. Where that block says N/A (Teredo, 6to4), the embedded IPv4 address decides.
  3. An address in no special-purpose block is reachable if it is IPv4 unicast or IPv6 global unicast (2000::/3). Other IPv6 space is reserved, so not reachable. Multicast depends on its scope, so it is null.
  4. Whatever the IPv6 block says, a non-reachable embedded IPv4 address makes the result false: 64:ff9b::a00:1 reaches the private 10.0.0.1 through a NAT64 gateway.

CIDR membership. Each cidrs entry (a strict address plus /prefix; host bits are ignored) reports contains. An IPv6 address also matches an IPv4 CIDR through its embedded IPv4 address (via: "embedded_ipv4"), so ::ffff:10.1.2.3 is in 10.0.0.0/8. At most 100 CIDRs.

Not covered. Host names are not resolved: use the address a name resolves to. IPv6 scope beyond link-local and multicast, and the IPv4 and IPv6 multicast sub-registries, are not analysed.

API & MCP

The same logic is available over HTTP and as MCP tools. Unlike this page, these run on the server: see where your data goes.