A public-IP check tells you the address an internet service sees for a particular request. It is useful when you compare connections or explain a problem to support. It is not a complete test of privacy, VPN coverage or device security.
Public and local addresses answer different questions
An IP address is a network address, as described in MDN’s IP glossary. The address shown in your device’s Wi-Fi settings may be a local address used within that network. The public address is the outward-facing address seen by the service you contact.
On a typical home connection, several devices may share an outward-facing IPv4 address. Mobile networks can also share addresses among customers. An address therefore does not reliably identify one person or one device.
You may see IPv4, written as four numbers separated by dots, or IPv6, written in longer colon-separated groups. Both are internet addressing formats. Comparing an IPv4 result with an IPv6 result is not the same as checking whether a single address changed.
Make a before-and-after check
Use our public-IP tool for this small experiment. It reads the public address visible to our server. If that check is unavailable, it can use GeoJS, which then receives the request and sees its public address. The result is an observation of your connection, not proof that a VPN is running.
- Choose one network and stay on it for the comparison. Record whether you are on home Wi-Fi, another Wi-Fi network or mobile data.
- With the VPN disconnected, run the check. Note the result privately.
- Connect the VPN and wait for the app to report its connection state.
- Run the same check again in the same browser.
- Compare the results and record the time of each check if you need support.
Avoid switching from Wi-Fi to mobile data halfway through. That changes the underlying connection and makes it harder to attribute the result to the VPN.
Interpret the result carefully
| What you observe | What it tells you | A sensible next step |
|---|---|---|
| The address changes after connecting | The service sees a different outward-facing address for the new request | Try the ordinary app or website you intended to use |
| The address stays the same | This check has not demonstrated a changed route | Confirm the app’s state and repeat under the same conditions |
| One tool shows IPv4 and another shows IPv6 | The tools may be observing different address families | Compare the same tool and note which format each uses |
| The check fails entirely | That request did not produce a usable result | Check ordinary browsing before diagnosing the VPN |
| An IP location label looks wrong | The lookup’s location information may not match your expectation | Compare the selected VPN location and ask the provider if it matters |
A changed address is one observation. It does not prove that DNS requests, another browser, a game or background applications take the same route. Conversely, one unchanged result does not identify the cause of a problem on its own.
Why a website can still recognize you
If you sign into your account on a website, that website knows which account you used regardless of the outward-facing IP. A delivery address you enter remains a delivery address. Changing network routing does not remove information you choose to provide.
That is why “my IP changed” and “this service no longer recognizes me” are different goals. Use the former as a connection check, not as evidence for the latter.
Keep IP results out of public screenshots
An address can reveal connection information, so avoid posting it in a public comment or an unredacted screenshot just to ask for help. Keep your initial support request focused on the symptom, app version, network type and timing. Supply an address privately if the support team needs it to investigate.
A useful initial report might say: “On Android using home Wi-Fi, the IP check returned the same address before and after connecting at 14:20 UTC. Ordinary browsing still worked.” That is more useful than a screenshot headed “VPN broken” and exposes less unrelated information.
Know when another test is needed
To investigate a specific app, reproduce the problem in that app. To understand service availability, check status. To work through a failed VPN connection, follow connection troubleshooting.
The public-IP tool does one small job. Keeping its result narrow makes it a more reliable part of your troubleshooting.