Most people think browser privacy begins and ends with cookies. Cookies matter, but a website can also observe connection and browser details before you ever create an account.
This post is a practical overview of the most common signals: your public IP address, WebRTC behavior, IPv6 availability, and browser fingerprinting.
Your public IP address
When a browser connects to a website, the server needs an IP address to send data back. That public IP can often be associated with:
- Internet service provider
- Approximate country, city, or region
- Network type, such as residential, mobile, or hosting provider
- Whether the connection appears to use a proxy or VPN endpoint
IP geolocation is not exact GPS. It is an estimate based on public databases and network routing information. A city result can be wrong, outdated, or represent the provider's infrastructure rather than the visitor's actual location.
Why WebRTC is worth checking
WebRTC is a browser technology used for real-time features such as voice calls, video calls, and peer-to-peer connections.
To establish those connections, browsers may gather network candidates. Depending on the browser, device, and privacy settings, this can expose details that differ from the normal IP address a website sees.
A simplified WebRTC check starts by creating a peer connection:
const connection = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});
connection.createDataChannel("check");
The browser can then generate ICE candidates as it prepares a connection. Modern browsers have added privacy protections, so results vary significantly. A WebRTC result is not automatically a “leak”; it is a signal that needs context.
IPv6 changes the picture
Many privacy checks focus only on IPv4. However, an IPv6-capable connection can have a separate public address path.
That matters because changing or masking an IPv4 address does not necessarily tell you what happens to IPv6 traffic. The right question is not “Do I have IPv6?” but “What does a website receive when my browser makes an IPv6-capable connection?”
Browser signals are not one thing
A browser fingerprint is not a single identifier. It is a collection of small signals that can include:
- Browser and operating system version
- Screen size and language
- Time zone
- Supported features
- Graphics and rendering behavior
- Device and hardware hints
Any one signal is usually ordinary. Combined signals can become more distinctive. This is why privacy is better understood as a spectrum than as a simple safe-or-unsafe switch.
How to interpret a privacy check
A useful privacy check should answer three questions:
- What information is visible?
- Is the result expected for this browser and connection?
- What setting or behavior could I review if I want to change it?
It should not create fear or claim that every visible detail is dangerous. Browsers need to reveal some information to communicate with websites, and different people have different privacy needs.
I built Privacy Leak Check as a simple browser-based way to review common IP, WebRTC, IPv6, and browser signals in one place. It requires no account or installation and is intended for informational checks, not as a security guarantee.
What browser privacy signal do you think is most misunderstood?
Top comments (1)
Really good framing, especially the distinction between a signal being observable and it actually representing a security or privacy issue.
I also like that you don't treat WebRTC results as an automatic "IP leak". The browser, network path, IPv4/IPv6 configuration and privacy settings all affect what is actually exposed, so the context matters.
From a security perspective, I'd be particularly interested in the correlation angle: individually low-sensitivity signals can become much more identifying when combined. That seems like an important distinction for a privacy checker to communicate, otherwise users can easily overestimate or underestimate the actual risk.
Nice work, and thanks for sharing the project! 🔐