Published Updated
An IP check is the cheapest diagnostic in networking: one request, and you learn which address a remote service actually saw. It is also the most over-interpreted. The result describes a network exit point at a moment in time — not a person, not a household, and often not even a city. This guide covers what the data is derived from, how far to trust each field, and how to compare address families and browser-level signals without drawing conclusions the data cannot support.
What an IP check can tell you
A public IP lookup answers one narrow question: which source address did this request arrive from, and what do routing and registry data say about that address. From that you can read the address family, the autonomous system number announcing the covering prefix, the organisation the prefix is registered to in a regional internet registry, and a geolocation estimate. The first three are facts about routing. The last one is an inference.
The address itself is the exit point of the path your packets happened to take. A carrier-grade NAT pool puts thousands of subscribers behind one address. A corporate gateway puts an entire office behind one address, in a city nobody in the office lives in. A mobile network may route a device through a gateway in a different region from the cell it is attached to. Treat an IP result as a property of the network path, not of a user.
Reliability drops sharply as granularity increases. Read this before you build anything that acts on a lookup result.
| Detail | Typical reliability | Derived from | Reasonable use |
|---|---|---|---|
| Address family and prefix | Exact | The packet headers and the routing table | Safe to act on directly |
| ASN and registered operator | Very high | BGP announcements and RIR registry records | Distinguishing datacentre from consumer or mobile networks |
| Country | High on fixed broadband, weaker on mobile, satellite and anycast | Registry allocation plus vendor measurement | Coarse routing, language defaults, regional content rules |
| Region or state | Moderate | Vendor inference | A hint to confirm against another source |
| City | Mixed; often the operator's regional hub | Latency and survey inference | Never the sole basis for a decision affecting a person |
| Postal code or coordinates | Low; commonly a country or region centroid | Interpolation and defaulting | Diagnostics only; do not display as the user's location |
| Street address or household | Not available | Nothing — it is not in the data | Any product claiming this is guessing |
Compare IPv4 and IPv6 behaviour
On a dual-stack network a single lookup tells you less than you think, because the browser chose an address family for you. Happy Eyeballs (RFC 8305) races an IPv6 and an IPv4 connection and keeps whichever completes first, with a bias toward IPv6. That means the same page can report an IPv6 address this morning and an IPv4 address this afternoon on an unchanged machine, purely because one path got slower.
The way to get a useful answer is to ask each family separately, through hostnames that publish only an A record or only an AAAA record. IP Network Check on this site works exactly that way: the browser connects straight to an IPv4-only detection host and an IPv6-only detection host, so a missing result is meaningful. If the IPv6 probe never returns, IPv6 is genuinely unavailable on that path — the operating system, the router, or the ISP is not providing it — rather than merely unselected.
Reading the two results side by side is where the diagnostic value is. IPv4 addresses on residential and mobile networks are frequently shared through carrier-grade NAT, so the address you see may be one of a pool and may change without warning. IPv6 addresses behave differently: the leading bits are the prefix your ISP delegates and are comparatively stable, while the interface identifier rotates on a timer if temporary address extensions (RFC 8981) are enabled. So an IPv6 address that changes every day is normal and expected; the prefix underneath it changing is the event worth investigating.
- An allowlist containing only 203.0.113.47 will reject this machine whenever IPv6 wins the race — a classic intermittent "it works for me" report.
- Allowlist the delegated IPv6 prefix (commonly a /56 or /64), never a single IPv6 address, because the low bits are designed to rotate.
# Force IPv4, against a host that only publishes an A record
$ curl -4 -s https://v4.example.net/ip
203.0.113.47
# Force IPv6, same machine, same minute, host only publishes AAAA
$ curl -6 -s https://v6.example.net/ip
2001:db8:4a3f:1100:5c2e:91ab:7d40:2e19
# Now the dual-stack production hostname — the stack picks for you
$ curl -s https://www.example.com/ip
2001:db8:4a3f:1100:5c2e:91ab:7d40:2e19
# Same request an hour later, after the v6 path degraded
$ curl -s https://www.example.com/ip
203.0.113.47Check browser WebRTC, IP, and DNS leak signals
A server-side lookup only sees the one connection that reached it. A browser-side check observes what the browser itself can reach, which is a different and often more revealing question. Browser Leak Check gathers IPv4 and IPv6 results over separate detection hosts, collects the ICE candidates a peer connection produces, and issues requests for fifty one-time subdomains of a controlled authoritative DNS zone so that the authoritative server can report which recursive resolvers actually performed those lookups.
WebRTC deserves a precise description rather than the alarm it usually gets. When a page creates a peer connection, the browser enumerates local network interfaces to build host candidates and asks any configured STUN server for its server-reflexive address. Modern browsers no longer hand raw private addresses to the page: host candidates are published as a random mDNS hostname ending in .local, so the private address is hidden from page JavaScript while still working for local peer connections. What is genuinely informative is the server-reflexive candidate, because that is the address a remote peer would see. If it does not match the exit you configured, browser media traffic is taking a path you did not intend.
The DNS portion works by observation, not by inspection. No browser API exposes the operating system's resolver configuration, so the only honest method is to make the browser resolve names nobody has resolved before and watch who asks the authoritative server. That reveals the recursive resolvers that served the query, which is usually what you wanted to know. Read the output with two caveats: large public resolvers are anycast fleets that may query from egress addresses in a different location than the one you contacted, and a resolver that forwards upstream will show its upstream rather than itself.
Use these signals as diagnostics. Sensible questions are whether a split-tunnel configuration is routing browser traffic the way you documented, whether a managed device is using the corporate resolver it is supposed to use, and whether an address family is silently missing. Unexpected results are a reason to look at the network configuration, not a verdict on it.
Read the ASN and network type
The ASN attached to a lookup is the autonomous system announcing the prefix that covers the address, together with the organisation registered as its holder. This is the most dependable non-trivial field in the whole result, because it comes from routing data and registry records rather than statistical inference. It is also the field that answers the question people usually have in practice: what kind of network is this. Hosting and cloud, consumer broadband, mobile carrier, business access and academic networks are treated very differently by the systems your traffic meets, so comparing ASNs between two environments is frequently the entire explanation for why one gets challenged and the other does not.
Two limits are worth stating. First, an ASN tells you who announces the prefix, not who uses the address: a single cloud provider's ASN covers an enormous number of unrelated customers, so "datacentre" is a statement about the network, not about intent. Second, reverse DNS is a weak signal. A PTR record such as host-203-0-113-47.pool.example-isp.net is set by the address holder, is not authenticated, and is often stale or absent entirely; use it as a hint that corroborates the registry data, never as evidence on its own.
Work within the quota and keep results comparable
The lookup services on this site are metered per visiting IP per UTC day. IP Info allows 1000 lookups, Proxy Check allows 500, and Site Check allows 10 because each site check is a full outbound request rather than a database read. The window resets at 00:00 UTC, which is not local midnight for most readers — if a batch job has been failing since mid-afternoon, work out where you are relative to UTC before assuming something broke.
The counter keys on the visiting address as the reverse proxy reports it in X-Forwarded-For. On a shared office or campus egress, everyone behind that address shares one budget. If a small team is investigating the same incident at once, that is worth knowing before you conclude the service is rate-limiting you unfairly.
Use IP data responsibly
In many jurisdictions, including under the GDPR, an IP address is personal data when it can be linked to an individual. That has practical consequences for how long you keep lookup results, who can see them, and whether they belong in a ticket that the whole company can read. Apply the same retention and access rules you would apply to any other identifier, and avoid compiling lookup results about addresses you have no operational relationship with.
Finally, be honest about what a check does and does not establish. Confirming that a lookup returns the address you expected tells you that one request took the path you configured. It says nothing about every other connection the device makes, about what an application-layer observer can correlate, or about traffic outside the browser. These tools are for finding out how your network is actually behaving so you can fix it — they are diagnostics, and reading them as a guarantee about anything else is a misuse of the data.
What to remember
- Treat an IP result as a snapshot of a network exit point, never as an identity: country and ASN are dependable, city and postal code usually are not.
- Query IPv4 and IPv6 through separate single-family hostnames, because a dual-stack browser silently picks one for you and the answer changes when a path degrades.
- Allowlist the delegated IPv6 prefix rather than a single IPv6 address, since the interface identifier is designed to rotate.
- Read browser WebRTC and DNS signals as observations — a server-reflexive candidate that does not match your expected exit is a reason to inspect the configuration.
- Quotas reset at 00:00 UTC and key on the visiting address, so save each result with a timestamp instead of re-running the same lookup.