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
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: —

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 expose public IP candidates during calls, chats or peer-to-peer features.
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 WebRTC public candidates against both your baseline IP and current VPN IP before calling it a leak.
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.

Verified VPN options to retest with

These cards appear only after the result, so the page stays tool-first. Use them when your verdict shows a leak or unstable DNS behavior.

NordVPN

Verified routing pick

Strong default option when you need predictable DNS behavior, low latency and a quick retest after a failed leak check.

  • Large server coverage helps compare nearby and distant routes fast.
  • Good default choice when the IP did not change or DNS still looks wrong.
  • Useful for rerunning the test after switching protocol or server location.
Retest with NordVPN

Surfshark

Good value retest

Useful when you want to retest DNS behavior and protocol changes on multiple devices without juggling separate licenses.

  • Unlimited-device model is practical for router, mobile and browser retesting.
  • Good candidate when one app profile behaves differently across devices.
  • Helpful for checking whether the issue follows the provider or the device.
Retest with Surfshark

Proton VPN

Privacy-focused retest

Solid option when you want another clean comparison point, especially after browser, DNS or IPv6 adjustments.

  • Good second-opinion provider when you need to isolate provider-specific behavior.
  • Practical for checking whether the leak survives across a different VPN stack.
  • Useful after disabling Secure DNS or changing IPv6 settings.
Retest with Proton VPN