Two people open the same browser test and see different address information. One concludes that a VPN is broken; the other concludes that the test is unreliable. Neither conclusion follows from a screenshot alone. Browser settings, network configuration and the test’s own scope belong to the observation. Without that context, comparing the screenshots is closer to comparing two unexplained error messages than repeating an experiment.
A developer can use IPDrop’s WebRTC check as an observation point while documenting that context. The purpose is to examine what this browser session exposes through this particular check, not to award a universal privacy certificate. This article describes a test method. It does not report a completed test of IPDrop, a VPN or a particular browser version.
Begin with the question the test can answer
An ordinary web request and a WebRTC connection do not necessarily provide the same view of networking. A page displaying the address of its HTTP request is reporting something different from a page examining information associated with real-time connection establishment.
MDN’s WebRTC connectivity overview describes ICE candidates and the negotiation used to establish connections. The practical implication is limited but important: candidate information has a context and a role. It should not be treated as a list of every possible way a device can be identified.
Write the test question narrowly. For example: does the chosen page display a public address that differs from the expected address for this browser’s current routing? That is more defensible than asking whether the device is anonymous. The latter involves accounts, identifiers, browser state and other information that an address check alone cannot settle.
FromDev’s general VPN-testing guide discusses request-address, DNS and WebRTC checks. A changed address or location label alone does not establish complete protection. The WebRTC specification’s privacy discussion explains why address exposure deserves attention beyond an ordinary page request. If a developer builds a minimal reproducer using an environment from FromDev’s JavaScript testing resources, its shared example should use synthetic values, not private network logs.
Record a baseline before changing settings
Use a browser profile intended for testing and record the browser version, operating system, network type and relevant extensions. Note whether a VPN is connected and whether it is a device-wide connection or a browser-specific proxy. Do not assume that two products using the word VPN route every process in the same way.
Keep the timestamp and the selected test page in the record. If the test displays several kinds of observations, preserve their labels. A result labelled as a request address should not become a WebRTC candidate simply because both resemble addresses.
Avoid uploading a screenshot containing a real address to a public issue tracker. Replace identifying values with consistent labels in the shared report, while retaining a private original if it is necessary for diagnosis. Address A and Address B can preserve the comparison without disclosing a household or workplace network identifier.
Change one variable rather than the whole environment
Turning on a VPN, changing networks, installing an extension and switching browsers at once may produce a different result. It does not identify which change caused it. Start with one relevant change, repeat the same observation and document what stayed constant.
For a routing comparison, keep the browser profile and test page fixed while changing the connection under examination. For a browser-policy comparison, keep the network fixed and record the exact setting changed. Restart or refresh only where the product’s own instructions require it, and include that action in the notes.
Repeating an observation can reveal variation, but a small number of trials does not establish a reliability percentage. Report what happened in each trial. “No address was displayed in three attempts” is a bounded observation; “this configuration can never expose an address” is a substantially stronger claim without supporting evidence.
Distinguish a negative result from a failed check
A page may show no candidates because of browser policy, an unavailable API, a script error, blocked network access or the way the check is implemented. These explanations do not all mean the same thing. An empty panel should therefore remain an unresolved result until the page explains what it successfully tested.
Look for a completion indicator or an error message before interpreting absence. Where the tool provides no technical detail, record that limit rather than inventing one. A developer should not quietly translate “test did not complete” into “no exposure found”.
The distinction matters when comparing configurations. If the baseline completed but a later attempt failed to run, there is no equivalent result to compare. Restoring the baseline and repeating the observation may help isolate a problem, but it still does not justify treating the failed attempt as a pass.
Interpret different addresses before labelling a leak
An address can have a different role from the one a reader expects. Local-network identifiers, public-facing addresses and relay-related information should not be collapsed into a single alarming category. Browser implementations can also change what is exposed or how local information is represented.
If the result includes an address believed to belong to the ordinary connection rather than the intended VPN route, verify the routing expectation against the VPN’s documented configuration. Split tunnelling, excluded applications or a browser-only proxy can materially change that expectation. The test cannot supply a missing configuration policy on the user’s behalf.
Do not infer a precise home address from an IP address or a coarse location estimate. Nor should a matching location label be treated as evidence that two underlying addresses are identical. Compare the actual labelled observation, using a private record where necessary, instead of relying on a country flag alone.
Preserve useful evidence without creating a new privacy problem
A practical test log can contain the date, environment, expected route, action performed, observed category and any error. Describe identifying values consistently, and keep private details out of public examples. Use synthetic addresses when demonstrating the report format rather than copying a real user’s result.
The log should also say what was not tested. A browser check does not establish the routing of every desktop application. It does not audit a VPN provider’s logging practices, certify server security or remove identifiers from accounts already signed in. Separating these questions makes the result more useful, not less.
The aim is a reproducible account of a specific observation. A small, well-described experiment can show that something changed and guide the next diagnostic question. A green badge without that context cannot explain what happened, and it should not be turned into a promise of anonymity.