What Is a WebRTC Leak?

You connect to a VPN, open a browser and expect websites to see the VPN's IP address instead of your own. Most of the time that is exactly what happens. But a feature called WebRTC, built into most browsers, can occasionally hand a website an address the VPN was supposed to cover. That is what people call a WebRTC leak.

This article explains what WebRTC is, why it can expose an IP address, how to test your own browser and what you can do to reduce the risk. It stays specific to the browser feature. If you want the broader picture of what hides and what does not, read Does a VPN hide your IP address?.

What WebRTC is

WebRTC stands for Web Real-Time Communication. It is a set of browser features, described in the MDN WebRTC documentation and standardised by the W3C, that lets web pages do things like video calls, voice chat, screen sharing and peer-to-peer file transfer without installing a plug-in. If you have joined a meeting in a browser tab, there is a good chance WebRTC was involved.

To set up a direct, low-delay connection between two people, WebRTC has to work out how they can reach each other. That is harder than it sounds, because most devices sit behind a home router and have a private address that nobody outside the network can use.

How a leak happens

To find a working route, the browser gathers a list of possible addresses, called candidates. It typically collects:

• Local addresses. The private address of your device on your home or office network, of the kind defined in RFC 1918, such as 192.168.x.x.
• Public addresses. The address the outside internet sees. To discover it, the browser asks a helper server (called a STUN server) "what address do you see me coming from?"
• IPv6 addresses. If your connection has them, these may be listed too.

A web page that uses WebRTC can read this list with a few lines of JavaScript. It does not need to start a real call, and in most browsers it does not need a permission prompt just to see the candidates.

Here is where the VPN can be bypassed. A VPN normally sends your traffic through an encrypted tunnel, and websites see the VPN server's address. But the STUN request is sent by the browser itself, and depending on your operating system and VPN setup it can go out through your normal network connection instead of through the tunnel. The helper server then replies with your real public address, and the page can read it.

A plain example

Imagine you connect to a VPN server in another city. A normal website sees the VPN's address, as expected. But a page with WebRTC code asks the browser for its candidates. The browser contacts a STUN server over your ordinary connection, learns your real public address from your internet provider, and lists it among the candidates. The page now holds two addresses: the VPN's and your own. The VPN did not fail in the usual sense. The browser simply asked a question outside the tunnel.

What can and cannot be exposed

Item	Can WebRTC expose it?	Notes
Your real public IP address	Sometimes	The main concern when a VPN is on
Local network address	Sometimes	Many current browsers replace it with a random-looking name unless you grant camera or microphone access
IPv6 address	Sometimes	More likely if your VPN setup does not handle IPv6
Pages you visit	No	WebRTC candidate lists do not contain browsing history
Content of your traffic	No	Still protected by the tunnel and by HTTPS

The practical risk is that a website, advertiser or other party can link your visit to your real network address. For most people that is a privacy inconvenience rather than a disaster, but it defeats one of the reasons you turned the VPN on.

How to test for a WebRTC leak

1. Note your real address first. With the VPN off, search for "what is my IP" using any IP-check page and write down the public address.
2. Connect the VPN. Make sure the connection is established before you open the browser.
3. Open a WebRTC leak test page. Several free ones exist. Search for "WebRTC leak test" and use one that explains its results.
4. Compare the addresses. If the test lists your real public address from step 1, the browser is leaking. If it lists only the VPN's address, or only a local name, you are fine for now.
5. Test each browser you use. Results differ between browsers and between private and normal windows.
6. Repeat after changes. Test again after updating the browser, changing VPN settings or installing an extension.

A test is a snapshot, not a guarantee. It tells you what happened at that moment on that network. The guide How to check if your VPN is working walks through a wider set of checks, and DNS leaks are worth testing in the same session.

How to reduce the risk

You do not need to be technical to make progress. Work down this list and retest after each step.

1. Update the browser and the VPN app. Browser makers have tightened WebRTC behaviour over the years, and updates matter.
2. Use the browser's own setting where one exists. Some browsers include an option that stops WebRTC from using anything except the VPN route. Firefox, for example, lets advanced users switch WebRTC off through its configuration page (the media.peerconnection.enabled setting).
3. Add an extension that restricts WebRTC. Several reputable extensions limit which addresses WebRTC may reveal. Pick one from the browser's official store with a clear description and recent updates, and read what permissions it requests.
4. Check IPv6. If a test reveals an IPv6 address you did not expect, your connection may be using IPv6 outside the tunnel. Your VPN app or operating system may have an option to handle or disable IPv6.
5. Use a browser profile for sensitive browsing. A separate profile with WebRTC restricted keeps the strict settings away from the browser you use for video calls.
6. Reconnect and retest. Settings changes sometimes only take effect after the browser restarts.

If you have trouble getting the VPN to stay connected while you test, see how to improve VPN connection stability.

Limits and what to watch for

• Disabling WebRTC has a cost. Video meetings, voice calls and some web games rely on it. If a meeting site stops working after you change a setting, that is probably why. Restrict instead of disabling, or keep one browser for calls.
• It only affects the browser. Standalone apps do not use the browser's WebRTC feature, though some apps have their own real-time features that behave differently.
• Your own device has to be trusted. WebRTC settings do not help if a page already knows who you are because you are signed in.
• A clean test does not mean anonymous. Sites can still recognise you through cookies, accounts and browser fingerprints. See can a VPN make you anonymous? for the honest answer.
• Tools differ. Different test pages may disagree. If one result looks odd, run a second page and the same test in a private window.

Summary

A WebRTC leak happens when your browser, using a feature meant for calls and video, asks for and reveals IP addresses outside the VPN tunnel. It exposes addresses, not your browsing content. Test with a WebRTC test page while the VPN is connected, update your browser, restrict or disable WebRTC where it makes sense and retest after each change.

If you are comparing options for protecting your connection, you can read about the prepaid pass options on the pricing page or browse the Help Center for setup and checking guides.