> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/concepts/what-is-webrtc.md).

# What Is WebRTC?

Video calls used to need a downloaded application. Now a link in your browser is enough. What changed — and why does a privacy tool care about it?

## Real-time media, built into the browser

**WebRTC** stands for Web Real-Time Communication. It is a set of capabilities built into every mainstream browser that lets a web page send and receive live audio, video and data.

Video meetings, browser-based voice chat, screen sharing, in-page customer support calls, some online games and some file transfer tools all use it. No plugin, no install.

The important design decision is this: for live media, WebRTC tries to send data **directly between the two participants** wherever it can, rather than routing everything through a company's servers.

That choice makes sense. A direct path is shorter, so the call has less delay. It also costs the service far less, because it is not paying to carry every second of every call.

But a direct connection needs something ordinary web browsing never needs: each side has to know how the other side can be reached.

## Why it has to go looking for addresses

Here is the problem. Almost nobody is directly on the internet. As explained in [Public, Private & CGNAT Addresses](/knowledge-base/concepts/public-private-cgnat.md), your device sits behind a router with a private address like `192.168.1.14`, which is meaningless to anyone outside your home. Your provider may add a second layer on top of that.

So your browser genuinely does not know its own public address, and it certainly does not know which combination of address and port the other side can reach it on.

WebRTC solves this by gathering options.

* It lists the addresses it can see locally — the private one on your network, and any IPv6 address.
* It asks a helper server on the internet, called a **STUN server**, a simple question: "what address do you see this message coming from?" The reply tells it the public address and port that its traffic appears from after passing through NAT.
* If direct connection turns out to be impossible, it falls back to a **relay server** (TURN), which forwards the media. This works everywhere but costs more and adds delay.

Each option it collects is called a **candidate**. Both sides exchange their candidate lists, then systematically try combinations until one works. That whole trial-and-error procedure is called **ICE** — Interactive Connectivity Establishment. It is a formal way of saying: collect every possible way of being reached, swap lists, and use whichever pairing succeeds first.

```mermaid
flowchart LR
    Y["Your browser"] -->|"what address<br/>do you see?"| S["STUN server"]
    S -->|"203.0.113.42:54321"| Y
    Y -->|"candidate list"| P["The other participant"]
    P -->|"candidate list"| Y
    Y -.->|"direct media if possible"| P
```

## Why this can reveal your IP behind a VPN

Now the privacy consequence becomes clear.

A VPN works by capturing your traffic and sending it through an encrypted tunnel. Websites then see the VPN's address instead of yours. That works well for normal browsing, where all traffic follows the same route your operating system was told to use.

WebRTC does not simply follow that one route. It deliberately enumerates every address and every path it might use, because its whole purpose is to find a way through. Depending on how your system and VPN are configured, that enumeration can turn up:

* your real public address, if some of your traffic escapes the tunnel — a **split tunnel** setup, or a browser extension VPN that only covers the browser's page requests
* your **IPv6** address, if the VPN only carries IPv4 and leaves IPv6 alone; this is a very common cause
* your **local network address**, which does not identify you globally but does reveal details about your network

A page can read these candidates with a small amount of JavaScript. It does not need permission, and it does not need to turn on your camera or microphone. That is what people mean by a "WebRTC leak": not a flaw in WebRTC, but a mismatch between what WebRTC is designed to do and what a VPN user assumes is happening.

## Reading the addresses a test shows you

A WebRTC test typically lists several candidates at once. They are not equally meaningful.

| What you see                               | What it means                                                                              |
| ------------------------------------------ | ------------------------------------------------------------------------------------------ |
| Something ending in `.local`               | The browser's privacy placeholder for your local address. Normal, and working as intended. |
| `192.168.x.x`, `10.x.x.x`, `172.16–31.x.x` | A real local network address. Reveals your network layout, not your identity.              |
| A public address matching your VPN         | Correct. The tunnel is covering WebRTC.                                                    |
| A public address that is *not* your VPN's  | A leak. This is the one that matters.                                                      |
| An IPv6 address while your VPN shows IPv4  | The most common leak of all — your VPN is not carrying IPv6.                               |

The useful comparison is always between the addresses WebRTC finds and the address a normal web request shows. If they disagree, something is escaping the tunnel.

## What browsers do about it

Browsers have tightened this over the years.

* **Local addresses are hidden by default.** Rather than exposing your real private address, browsers now supply a randomised placeholder — an mDNS name ending in `.local` — unless the page has already been granted camera or microphone access.
* **Fewer addresses are gathered up front.** Modern browsers collect a narrower set of candidates until a call is genuinely being set up.
* **Policy settings exist.** Some browsers and extensions let you restrict WebRTC to the default route only, or disable it entirely.

These help, but they do not close the case. A public address discovered through STUN is still a public address, and the IPv6 gap is a configuration problem on your side, not something the browser can fix for you.

Turning WebRTC off completely is an option, with an obvious cost: video calls in your browser stop working. Most people are better served by fixing the underlying leak — using a VPN that handles IPv6, or one that operates at the system level rather than only inside the browser.

## Common misconceptions

**"WebRTC is spyware."** It is a standard feature for real-time media, used by tools you rely on. The address discovery is necessary for the connection to happen at all.

**"A WebRTC leak means my VPN is broken."** More often it means your VPN is incomplete — usually missing IPv6, or only covering browser page loads.

**"If the test shows a `.local` address, I am leaking."** No. That is the browser's privacy placeholder working correctly. What matters is whether a real public address appears that is not your VPN's.

**"Incognito mode stops it."** It does not. Incognito affects storage and history, not network behaviour.

{% hint style="info" %}
**See it yourself on MyIP**

The **WebRTC Leak Test** on the dashboard runs exactly this discovery process and shows every address WebRTC finds. If your VPN is on and one of those addresses is not your VPN's, your proxy settings are not covering these connections. It also estimates your NAT type — useful context for games and calls, though the detection is a best guess rather than a certainty.

Full walkthrough: [WebRTC Test](/knowledge-base/connection-tools/webrtc-test.md).
{% endhint %}

## Related concepts

* [Public, Private & CGNAT Addresses](/knowledge-base/concepts/public-private-cgnat.md) — the NAT layers WebRTC is working around
* [IPv4 vs IPv6](/knowledge-base/concepts/ipv4-vs-ipv6.md) — why IPv6 is the usual leak path
* [Latency, Jitter & Packet Loss](/knowledge-base/concepts/latency-jitter-packet-loss.md) — the metrics that decide whether a call sounds good
* [Am I Leaking My Real IP?](/knowledge-base/diagnose/am-i-leaking-my-real-ip.md) — the full leak checklist


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/concepts/what-is-webrtc.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.