How to run an IP comparison
An IP comparison shows whether several named HTTP destinations observe the same public address from your browser. Start with the cards above: each identifies the service that receives its own request. Select Compare IP addresses, leave the tab open, and wait for each card to finish. A result can contain an address, a timeout, an unavailable response, or an unexpected response. These outcomes remain separate because an IP comparison needs visible evidence rather than a single pass or fail badge.
The page sends requests directly from your browser. It does not ask our backend to visit those services on your behalf. That distinction is essential: a server making the requests would reveal its own exit, which says little about your browser's proxy rules. The IP comparison starts only when you press the button. Opening this guide does not automatically contact the listed external services. Our home page separately displays the address observed for your initial visit, with a clearly identified fallback when necessary.
You can stop an IP comparison while requests are running. Completed cards remain available, and unfinished cards become stopped rather than successful. Running again replaces the previous set of observations. Clear results removes the displayed set and cancels pending work. Hide addresses conceals address text in these cards; it does not change your connection or prevent services from seeing it. A copied IP comparison report includes public addresses, destination URLs, statuses, and timestamps, so review that report before sending it to anyone.
Read an IP comparison by address family
For an IP comparison, first inspect the destination, then the IP version, and finally the address. The IP comparison evaluates IPv4 observations against other IPv4 observations and IPv6 observations against other IPv6 observations. It does not call one IPv4 address and one IPv6 address a routing mismatch. A dual-stack connection can legitimately use both. If the run returns only one address of each version, there is not enough same-version evidence to compare, even though both requests succeeded.
When two destinations report different addresses in the same version, the IP comparison reports different observed exits. Possible explanations include destination-based proxy rules, a corporate gateway, several upstream connections, or an address change during the run. The result establishes the observed difference; it does not establish its cause. Check your intended routing rules before interpreting the IP comparison as a fault. If an organization intentionally separates work and public browsing, different exits can be expected behavior.
Matching IP comparison results have a narrower meaning than complete privacy. They show that the available same-version observations agree during this run. They do not prove that another application, another hostname, or another protocol follows the same route. An IP comparison with two matching responses and one unavailable response remains incomplete for that missing destination. Read the observed count together with the summary, rather than treating the summary as a certificate that every request reached the same exit.
Each completed IP comparison card includes the browser's receipt time in UTC and the HTTP completion duration. The duration includes browser scheduling, connection setup when needed, transport, service processing, and receiving the response. Connection reuse can change it substantially. The IP comparison does not send ICMP echo packets, and its duration is not a conventional ping measurement. Avoid ranking providers by one such number or comparing it directly with a game's latency display.
What the listed destinations represent
The default IP comparison uses this website's public address endpoint, ipify's dual-stack endpoint, and Cloudflare's trace endpoint. The hostname and path appear in each card before you start. Our endpoint reports a trusted request address and refuses to invent one when a trusted public observation is unavailable. A failure on our endpoint stays visible in the IP comparison; the tool does not silently replace it with another provider and relabel that provider's result as ours.
The ipify documentation describes its IPv4, IPv6, and combined public-address endpoints. This IP comparison uses the combined endpoint, so the successful response may use either protocol. For separate protocol checks, use the IPv6 test. A domain's location or ownership does not by itself tell you where a particular request was served, nor does it tell you what all sites in that region would observe.
Cloudflare documents its trace endpoint as a troubleshooting facility. We read its address field for this IP comparison and discard unrelated response fields. Cloudflare has a distributed network, so a response from its hostname is not evidence that your browser reached a dedicated server in one fixed country. The card labels the service actually requested. It does not rename Cloudflare as an entire continent or as another company's network.
The IP comparison can also display operator-configured regional echo nodes when such nodes are available. Their declared region appears separately from the observed address. A region label describes the destination's intended hosting location; it is not geolocation of the visitor's address. If no dedicated nodes are configured, the page says so. In that state, the IP comparison does not offer a measured mainland China versus overseas result, and the default run makes no request to Google.
Investigate proxy and VPN routing
Destination-dependent behavior is useful to investigate when a proxy uses hostname rules or a VPN includes only selected routes. Before an IP comparison, note which applications and destinations your configuration is intended to cover. Do not assume that a browser extension also controls background applications. The Microsoft routing documentation explains the distinction between split and forced tunneling on its platform. Other operating systems and clients have their own configuration details.
Run the IP comparison without changing network settings during the short measurement window. If you then change a proxy rule, rerun and compare the two reports while keeping other conditions as similar as possible. The tool does not operate your VPN or change system routes. On a managed device, use the settings and troubleshooting process authorized by your organization. An unexplained IP comparison difference is a reason to inspect configuration, not a reason to disable protections indiscriminately.
Consider a hypothetical run in which two IPv4 cards show one address and the third shows a different IPv4 address. Record which exact hostname produced the third result. Then inspect whether that hostname matches a separate rule or route. Repeat the IP comparison to see whether the distinction persists. If it disappears, an address rotation or transient connection change may be involved. This example is explanatory; it is not a live result or a finding about any particular provider.
Another IP comparison may return an IPv6 address for one destination and IPv4 addresses for two others. Compare the two IPv4 values, then use the separate protocol tool to investigate IPv6 availability. Do not describe the IPv6 response as an automatic leak. Whether either address is expected depends on your intended setup. The IP comparison reports observations and their scope, while your configuration determines what those observations should have been.
Unavailable responses and other limitations
An unavailable IP comparison card does not tell you why a request failed. DNS resolution, TLS negotiation, an extension, a proxy policy, a service outage, or the service's cross-origin rules can each prevent a readable response. Browsers intentionally conceal some error details from page scripts. The MDN CORS guide explains why a server must permit a page to read its cross-origin response. The IP comparison therefore avoids declaring a destination blocked solely because the IP comparison did not obtain an address.
Each request has an eight-second limit. A timeout means the operation did not finish within that window; it does not prove permanent unreachability. A rate-limited card means the service asked the caller to slow down. Wait before rerunning an IP comparison rather than repeatedly pressing the button. An unexpected-response card means the body did not match the expected address contract. HTML error pages, private addresses, conflicting protocol information, and ambiguous address fields are not accepted as successful measurements.
The IP comparison does not perform DNS leak detection, WebRTC candidate gathering, packet capture, or a traceroute. Those mechanisms complement an IP comparison by observing different parts of a connection. The WebRTC leak test gathers browser candidates with its own disclosure and limitations. The DNS lookup queries a named resolver and is not a measurement of which recursive resolver your browser used. Keeping these distinctions visible makes an IP comparison easier to interpret alongside other tools.
All IP comparison addresses here are observations reported by the named receiving services. HTTPS protects transport to each endpoint, but it does not independently audit that provider's infrastructure or prove its response is accurate. Services can change, become unavailable, or change their integration behavior. An IP comparison should therefore preserve the destination and timestamp when documenting a problem. Do not remove these fields from a support report and leave only an unexplained address list.
IP comparison questions
Does this test access to Google or every overseas website? No. The IP comparison contacts only the URLs displayed in the cards. A response from a different hostname cannot establish which address Google sees, even if a proxy currently groups both names under one rule. Testing a named service requires a suitable observation from that service or a clearly documented, separately scoped connectivity check. The page does not infer that result from branding or assumed routing lists.
Can I use this to find my physical location? No. An IP comparison identifies public request addresses, not GPS coordinates or a street address. The declared location of a regional node refers to the destination. Registration records and IP geolocation databases describe other evidence with their own limits. If you want to understand an observed address, copy it into the IP lookup and keep registration information separate from physical-location claims.
Will the report include another browser's connection? No. An IP comparison runs in the browser tab where you start it. Another browser, an application-specific proxy, or a device on a different network may follow another route. Refresh the measurement after a network change. Navigating away clears this tool's in-memory result instead of treating a previous observation as current when you return.
What information leaves this page? The listed destinations receive ordinary HTTPS requests from your browser and can observe the connection used to reach them. Requests omit credentials and referrer information. The tool does not place its result in a public URL or store it in browser storage. An IP comparison report is copied only when you select the copy action; receiving services may retain their own request logs under their policies.
What should I do after finding a difference? Keep the full report, identify the address family and hostname involved, and compare that evidence with your intended route. Repeat under a stable configuration, then investigate the specific rule or connection that differs. The most useful IP comparison is one tied to a concrete troubleshooting question. It helps explain browser exits without turning a small set of observations into a claim about the safety of an entire device.
MyIP.dog