01 / Evidence model
What we observe, and what we infer
The distinction that matters most on this site is not which tool produced a value, but how much trust that value has earned. A resolver address that answered a live query is not the same kind of fact as a city guessed from an IP block, even when both appear in the same panel. Four labels carry that difference through every result.
Obtained directly during the current test — the address a request arrived from, the resolver that performed a lookup, the candidates a browser reported.
Produced deterministically from an observed or supplied value. Prefix boundaries, address counts and range conversions fall here. Same input, same output, every time.
Context pulled from registration, routing or routing-security data. Accurate while those datasets are current and agree with each other.
An interpretation or estimate. A location, a “this looks like a leak” reading. Useful for direction, not for proof.
| Signal | Type | Source / method | What it tells you | Limit |
|---|---|---|---|---|
| Public IP | Observed | Source address of the HTTP connection | The address at your network egress | Not a person or a device |
| IP version | Derived | Address format | IPv4 or IPv6 for this request | The other family may differ |
| Origin ASN | Enriched | Observed BGP (RIPE NCC RIS) | Which AS currently originates the route | Not necessarily the retail ISP brand |
| Registrant | Enriched | RDAP at the responsible RIR | Who the block is allocated to | May differ from who routes it |
| City / region | Inferred | Edge IP geolocation | Roughly where the network sits | Not where the device is |
| DNS resolver | Observed | First-party authoritative DNS test | The resolver that queried the test name | Only the path that was exercised |
| WebRTC candidate | Observed | Browser ICE gathering | Addresses the browser would offer a peer | Browser policy changes what appears |
| CIDR result | Derived | Binary prefix arithmetic | Exact network, range and mask | Requires a valid input |
| RPKI state | Enriched | Route Origin Validation via IPRevealed US1 | Whether the route matches a signed authorization | Reflects routing and ROA state at check time |
02 / Public connection
The address seen at the egress
When a request from your browser reaches one of our endpoints, the connection carries a source address. That address is what any server on the internet sees, and it is what we report as your public IP. It is chosen by the last piece of network that hands your traffic to the public internet — your router, your ISP’s NAT, a carrier-grade NAT shared across thousands of subscribers, or a VPN server.
What it is not
- Not your LAN address. 192.168.x.x and 10.x.x.x live inside your network and never leave it.
- Not a single device. NAT and CGNAT put many machines, sometimes many customers, behind one address.
- Not an identity. It marks a point of egress, nothing more.
If your connection runs dual-stack, IPv4 and IPv6 requests can leave over different paths and return different addresses. Several tools test each family on its own for exactly that reason. With a VPN in place the egress address should become the VPN server’s; seeing your own ISP address there is the kind of inconsistency the privacy diagnostics are built to surface.
03 / Network identity
Routing is not registration
Ask “whose address is this?” and there are two honest answers. One comes from the registry that allocated the block. The other comes from the routing table that carries traffic for it today. They usually point at the same organization. When they don’t, the gap is informative, so IP Lookup keeps them in separate panels rather than reconciling them into one label.
Registration RDAP · RIR
Who the block is allocated to in the records of the responsible Regional Internet Registry — ARIN, RIPE NCC, APNIC, LACNIC or AFRINIC. Read live over RDAP, the structured protocol that replaced WHOIS.
Routing BGP · RIPE NCC RIS
Which Autonomous System is currently announcing a path to the block, taken from observed BGP data. Treat this ASN as the present route origin, not as ownership and not as the brand on your bill.
Route Origin Validation
An address holder can publish a signed Route Origin Authorization — a ROA — naming the AS allowed to originate a prefix. We check the observed route using IPRevealed's independent US1 RPKI validation service.
04 / Location
A geolocation estimate is a network estimate
An IP location is a guess about where a network sits, not where a device is. IPRevealed never asks the browser for location permission and never uses GPS.
When the site shows a country, region, city or approximate coordinates, that value is a geolocation estimate our edge network derives from the IP address. How close it lands to you depends entirely on how the network in front of you is built.
Common reasons the estimate drifts:
- the ISP’s infrastructure or a regional gateway is nearer the registered location than you are;
- a mobile carrier routes through a centre in another city entirely;
- a VPN reports its exit location;
- an enterprise sends everyone out through one egress, sometimes in another country;
- the address is anycast, announced from many places at once, so a single location is meaningless.
Country-level results hold up well. Below that, the interface says Approximate location and IP-based estimate because that is what the data supports.
05 / Privacy diagnostics
Three tests, one idea
The VPN, DNS and WebRTC checks all rest on the same move: gather several signals that should follow the same path, then report whether they agree. None of them inspects your device or tries to name the software you are running. They differ in which signals they collect and how those signals are produced.
Five paths — the normal web path, forced IPv4-only and IPv6-only requests, WebRTC candidates and DNS resolver observations — are compared against each other. The output is graded evidence, not a verdict, because a mismatch has innocent explanations: split tunnelling, IPv6 the VPN doesn’t carry, provider design. It flags what looks inconsistent; deciding whether that is a leak still needs knowledge of your own setup.
A one-time hostname is generated under authoritative DNS that IPRevealed runs. When your browser resolves it, the first-party nameserver records the resolver that actually made the query. A resolver outside your expected setup — an ISP resolver while a VPN is up — can point to a leak, but resolver operators run regional pools, IPv4 and IPv6 can take different instances, and encrypted or enterprise DNS shifts what “expected” means. Geography on its own proves nothing.
The test opens a local peer connection with a dummy data channel — no media, no camera or microphone — and reads the ICE candidates the browser gathers. A STUN server we operate returns the browser’s server-reflexive address, normally identical to the one every site sees. It matters only when it differs. A randomized .local mDNS name in place of a private address is standard browser behaviour; a private LAN address by itself is not a leak. A differing public address is, and it can appear when a VPN leaves some UDP outside its tunnel.
What would actually count as evidence?
06 / Network mathematics
Deterministic computation
The planning tools sit apart from everything above. Nothing is observed or enriched. Given a valid prefix, binary arithmetic fixes the answer, and it runs in your browser with no request to any server.
| Tool | Computes |
|---|---|
| Subnet Calculator | Network and broadcast address, usable range, mask and wildcard, address count and class for an IPv4 or IPv6 prefix. |
| VLSM Calculator | Right-sized subnets fitted into one block from a list of host counts, with utilisation and leftover space. |
| Subnet Splitter | An even division of a network into equal subnets by prefix, count or host capacity. |
| CIDR & IP Range Converter | CIDR to first–last range and back, as the smallest exact set of prefixes. |
| Subnet Overlap Checker | Containment, duplication, adjacency and conflict across a list of networks. |
| Route Summarization Calculator | The smallest exact prefix set for a group of routes, and the smallest single covering supernet. |
The tools follow the standard reading of edge cases: a /31 as a two-address point-to-point link with no broadcast, a /32 as one host, and IPv6 prefixes such as /64 and /127 on their own terms rather than by IPv4 analogy.
Worked example: exact versus covering
Input 172.16.0.0/24 and 172.16.4.0/24
Exact representation
172.16.0.0/24 + 172.16.4.0/24
No single prefix aggregates these two without also pulling in 172.16.1.0/24 through 172.16.3.0/24.
Covering supernet
172.16.0.0/21
Covers 2,048 addresses. The two inputs are 512. The supernet adds 1,536 addresses you did not list.
A covering supernet is convenient in a routing table but it is not lossless. The Route Summarization Calculator reports both, and the extra count, so the trade-off is explicit.
07 / Data freshness
Different data ages at different rates
A result is a snapshot taken at or near the moment of the lookup. Some of its inputs were true seconds ago and some were last updated weeks ago, so the same address can read differently on a later visit without anything being wrong.
- Request signalThis request only.
- DNS pathThis test only; can differ between sessions.
- BGP routingChanges continuously as networks re-announce.
- RPKIChanges whenever a ROA is issued or revoked.
- RDAP registrationChanges on administrative updates at the registry.
- GeolocationA provider estimate; can lag real-world change by a long way.
08 / Privacy
What the test needs to see
Each check has a minimum it cannot work without, and that is all it asks for.
- Public IP — the source address of your request.
- DNS — your browser resolving one temporary hostname.
- WebRTC — a local peer connection with no media.
- IP Lookup — the address you type in.
What the test does not request
No browser geolocation permission. No camera. No microphone.
Beyond the test itself, ordinary web plumbing still applies: the CDN, the web server and the edge that answers connection lookups all process normal request metadata, including your IP address, to return a response. What is kept, and for how long, is covered in the Privacy Policy. The homepage is built so the connection details you see there are fetched by your own browser after load and never baked into the cached HTML other visitors receive.
09 / Limitations
What a signal can and cannot establish
| Signal | Can establish | Cannot establish |
|---|---|---|
| Public IP | Your network egress address | A person, or a specific device |
| ASN | The current route origin | A retail ISP relationship, or ownership |
| IP location | An approximate network location | Physical presence, or a device position |
| DNS resolver | The resolver on the tested path | A privacy failure, on its own |
| WebRTC candidate | Addresses the browser would offer | A compromise, from a local candidate alone |
| RPKI “not found” | That no ROA covers the prefix | That the route is wrong or hostile |
Beyond those, the environment sets hard limits. CGNAT and mobile networks share one address across many users. Proxies, VPNs and enterprise egress move the observed connection away from the person behind it. Anycast has no single location. Browser privacy features keep changing what client-side signals reveal, and they differ by browser and version. Registry, routing and geolocation datasets each carry their own lag between a real change and its publication.
10 / References
Engineering notes
- RDAP
- RFC 9082 query format, RFC 9083 JSON responses — the protocol used for live registration lookups.
- BGP
- RFC 4271 — the inter-domain routing protocol behind these announcements. IPRevealed reads routing visibility observed by RIPE NCC’s RIS route-collector network through the RIPEstat API.
- RPKI
- RFC 6480 the infrastructure, RFC 6811 prefix origin validation — how the valid / invalid / not-found states are defined.
- CIDR
- RFC 4632 — classless addressing and aggregation, the basis of every planning calculation.
- IPv6
- RFC 4291 addressing architecture, with RFC 1918 and RFC 6598 for private and shared IPv4 space.
- Browser networking
- RFC 8445 ICE, and the W3C WebRTC API — how candidates are gathered and what a browser exposes.
- Number resources
- IANA — the allocation hierarchy above the five Regional Internet Registries.
Put the method to work
Every method on this page runs from one place.
The same connection diagnostics, routing intelligence and network calculations described above.
Explore IP & Network Tools