Leak Test — Check IP, DNS, WebRTC & IPv6 Leaks

Use it in two ways: run a quick standalone check to see your current IP, DNS, IPv6 and WebRTC exposure, or save a baseline first and compare it with a VPN session. The verdicts explain what changed, what that means and what to fix next.

Quick check or baseline vs VPN DNS / IPv6 / WebRTC checks No logs stored in normal flow
Leak & Privacy Test
SmartAdvisorOnline Tools • Baseline vs Now
waiting
Step 1 — Quick check or baseline not saved
Click Run Baseline to save your current network snapshot. This is optional if you only want to check your present IP, DNS, IPv6 and WebRTC state.
Step 2 — Current network / VPN compare not run
Click Run Now to inspect the connection you are using right now. If VPN is enabled, the tool compares it with baseline; if not, it still works as a standalone check.
Step 3 — Read verdicts waiting
Use the cards below the results to understand each signal, what it affects, and what to do if something leaks.
Status: Start with Baseline (VPN OFF).
Last baseline saved: —
Quick tips
• You can use this as a standalone network check to see your current IP, DNS, IPv6 and WebRTC exposure.
• For a real VPN comparison, save Baseline first, then run Now with VPN enabled.
• WebRTC public candidates are not automatically a leak — the key question is which IP appears there.
• DNS pointing to your ISP, router or browser Secure DNS while VPN is ON can indicate a leak or a local stub situation.
No logs policy
This tool reads signals in your browser and renders the result on the page. We do not store your leak-test logs, comparison history or copied report on our servers as part of the normal test flow.
Technical documentation
Methodology and architecture notes for this tool:
dev.to article
GitHub repository
Connection map
Pins show where your IP appears to be located (approximate). Baseline is your normal connection; Now is after you enable a VPN. We also show country flags and city labels when available.
Baseline: —
Now: —
30°N 60°N 30°S 60°S

Understand the result, not just the numbers

These cards stay hidden until you run the test. Use the first tab for a standalone privacy check, or switch to the comparison tab after you save baseline and test again with VPN.

Visible after test
Your current IP, DNS, IPv6 and WebRTCOpen

Run the test once and this card will explain what your current network exposes right now.

  • Public IP: the visible address websites and services can see from your current connection.
  • DNS resolvers: the systems that translate domains into IPs. They often reveal whether requests follow your ISP, router, browser Secure DNS or VPN tunnel.
  • IPv6: another network path that can stay visible even when IPv4 looks protected.
  • WebRTC: browser connectivity data that can show your current public path, an older pre-VPN path, or no useful public path at all.
When a standalone check is enoughOpen
  • Before using public Wi‑Fi: verify what your current connection exposes before logging in anywhere important.
  • After changing browser settings: Secure DNS, iCloud Private Relay, browser privacy extensions or router DNS may change the result.
  • When a site localizes you strangely: your visible IP, DNS or IPv6 path may explain the mismatch.
  • Before enabling VPN: this creates a mental baseline even if you do not save the formal baseline snapshot yet.
No logs and what we actually keepOpen
  • No server-side leak logs in normal flow: the page does not build a long-term personal history of your tests on our servers.
  • Your export is manual: JSON export or copied report happens only when you trigger it yourself.
  • Browser state is temporary: baseline exists so you can compare sessions, not because we want a profile of your traffic.
  • What matters: the test shows exposure, then lets you decide whether to save, export or reset.
What to do if one signal looks wrongOpen
  • IP looks wrong: reconnect, change server, verify kill switch and split tunneling.
  • DNS looks wrong: disable browser Secure DNS for testing, enable VPN DNS, retry with a closer server.
  • IPv6 still visible: use VPN IPv6 protection or temporarily disable IPv6 on the device/router.
  • WebRTC still confusing: compare the WebRTC IP with your visible public IP. Matching current IP is usually fine; matching old IP is not.
What changed between baseline and VPNOpen

Save baseline first, then run the test again with VPN enabled. This card becomes the plain-English comparison layer.

  • Protected: your visible IP changes, DNS path changes as expected, IPv6 does not suddenly leak, and WebRTC shows only the current VPN-facing IP or nothing useful.
  • Suspicious: one layer still points back to your old route, your ISP resolver, or a browser-controlled Secure DNS path.
  • Leak detected: the old public IP survives, or WebRTC still exposes the pre-VPN public IP.
  • Best practice: change one variable at a time, rerun, and compare again.
How to read each comparison lineOpen
  • Public IP: should change when VPN is meant to protect the browser traffic.
  • DNS: should not keep resolving through the same ISP or router path unless you intentionally configured it that way.
  • IPv6: should not appear only after VPN turns on unless the VPN handles IPv6 intentionally and cleanly.
  • WebRTC: compare public candidates against both your baseline IP and current VPN IP. Matching the old IP is the strongest warning sign.
Most common leak scenarios and fixesOpen
  • IP did not change: reconnect, switch server, disable split tunneling, verify app permissions.
  • DNS still looks local or ISP-based: disable browser Secure DNS for testing, enable provider DNS inside the VPN app, retest.
  • IPv6 appears only with VPN: use a VPN with IPv6 support or disable IPv6 at OS/router level and retest.
  • WebRTC shows the old IP: disable WebRTC IP exposure in the browser, use a different browser, or check for extensions overriding proxy paths.
Why beginners should rerun after every fixOpen
  • One fix can hide another issue: changing DNS may not fix WebRTC, and changing server may not fix IPv6.
  • Comparison is your proof: the safest way to learn is to see what actually changed after each tweak.
  • Good habit: test once after app install, again after protocol change, and once more after browser or router tweaks.
  • Return value: this turns the tool into a repeatable checklist, not a one-time screenshot.

VPN providers we regularly verify in our lab

These are VPN providers we test regularly for DNS handling, route stability and leak resistance. Use them as a next step only after you read your result and decide you want to retest with a stronger or cleaner setup.

NordVPN

Verified routing pick

One of our most consistent picks when you want stable DNS routing, fast reconnects and a clean follow-up retest after a suspicious result.

  • Frequently shows clean resolver behavior in repeated desktop and mobile retests.
  • Useful when your public IP did not switch cleanly or DNS still looks tied to the old route.
  • Good for rerunning the test after changing protocol, server city or app settings.
Check NordVPN

Surfshark

Good value retest

A strong value option when you want to compare DNS behavior across several devices and check whether the same issue repeats everywhere.

  • Practical for phone, laptop, browser and home-network retesting under one account.
  • Helpful when one device looks clean but another still shows unstable DNS or WebRTC behavior.
  • Good for testing whether the problem belongs to the device setup or the VPN stack itself.
Check Surfshark

Proton VPN

Privacy-focused retest

A privacy-focused comparison point when you want to verify whether a leak survives after browser DNS, IPv6 or app-level changes.

  • Useful as a second-opinion provider when you want to compare resolver ownership and route consistency.
  • Helps confirm whether the issue is provider-specific or still present across a different VPN setup.
  • Worth testing after you disable Secure DNS, switch browsers or change IPv6 handling.
Check Proton VPN

Deep DNS Lab

This is the advanced layer of the leak tool. Instead of checking one DNS request, it fires a burst of 20 unique probes, waits for the resolver path to stabilize, then explains whether you are seeing a single clean resolver cluster, mixed ownership, or partial DNS behaviour that deserves closer review.

advanced mode
20 real DNS probes resolver ownership review plain-English guidance

What this mode is built to catch

Inconsistent routing

Some queries follow one path, later queries follow another. A quick test can miss that.

Partial DNS handling

Only part of the burst returns before timeout. That often points to unstable DNS routing or filtering.

Mixed resolver ownership

The dangerous pattern is not “many IPs”, but “different networks or providers in the same burst”.

Actionable next step

After the result, the lab explains what the pattern means in technical terms and in plain language.

Session
Unique lab session for the current DNS burst.
Checks completed
0/20
How much usable data came back from the 20-probe burst.
Resolvers seen
0
How many resolver IPs appeared. One stable path is usually easier to trust than a mixed result.
Verdict
Idle
Run the sweep to see whether DNS stayed on one stable path or needs review.

Deep status

Deep test idle.

Resolver board

This board lists every resolver IP seen during the burst. What matters most is whether they stay on one stable DNS path or split across different groups.

No resolver events yet.
A single resolver path across all 20 probes is the cleanest result. Multiple resolver IPs are not automatically a leak, but they deserve context.

Your deep result, explained

ResultRun Deep DNS Sweep to generate your advanced breakdown.
Why it mattersThis table translates the burst into a user-facing explanation and a technical interpretation.
Risk levelWaiting for data.
Next stepNo action yet.

Technical details will appear here after the burst. The lab will explain probe completion, resolver ownership, and whether the result looks like one stable DNS path or a mixed route.

Simple explanation will appear here after the burst. This tab turns the result into plain language and a clear next action.

No next step yetRun the deep sweep first. After that, this section will tell the user exactly what to do next.

VPN DNS leak protection

What DNS leaks are, why they happen, and which settings usually fix them.

Open DNS leak guide

VPN troubleshooting

Use this when the burst shows partial or unstable behaviour and you need a structured fix path.

Open troubleshooting guide

VPN speed test

If DNS looks clean but browsing still feels slow or unstable, cross-check latency, download and upload performance.

Open speed test

Public Wi-Fi VPN guide

Useful if the burst was run from a café, hotel, airport or shared network with unusual DNS handling.

Open public Wi‑Fi guide
Deep DNS raw result

VPN providers we regularly use in DNS leak checks

These recommendations stay hidden until the deep test finishes. They are shown only after the diagnostic result, so the recommendation comes after the evidence—not before it.

NordVPN

Strong DNS consistency, fast apps, and a good default choice when you want fewer surprises across desktop and mobile.

  • Good track record for stable app-level DNS handling
  • Fast enough to pair with the speed test after diagnosis
  • Solid default pick for users who want fewer manual tweaks
Check NordVPN

Surfshark

Good value for users who need multiple devices and want to compare DNS behaviour across phone, laptop and TV.

  • Useful when you want one account across many devices
  • Often a practical option for household-wide testing
  • Reasonable choice when you want lower cost per device
Check Surfshark

Proton VPN

Good for users who care about a more privacy-focused stack and want another reference point when comparing resolver behaviour.

  • Useful as a second opinion when comparing resolver ownership
  • Strong fit for privacy-first users
  • Worth testing if your current app shows mixed DNS paths
Check Proton VPN