They answer different questions, and we'd recommend both. The combined scan is fastest for a general health check and for catching a signal you weren't thinking to test — like a timezone mismatch you didn't know was a leak vector. The dedicated single-purpose tests (WebRTC, DNS, IP) go deeper on that one signal — for example, the standalone WebRTC test shows every individual ICE candidate with type and IP, which the summary card here condenses into a single pass/fail badge. Use the full scan to find where to look, then the specific test to see exactly what's happening.

This usually means the two tests ran under different conditions, most often because a VPN connection state changed between the two tests, or because the WebRTC leak test was run in a different browser tab or profile than the full scan. Both tools use the same underlying detection logic, so if conditions are identical, results should match — re-run both within the same tab, back to back, to confirm.

There's no universal passing number, because the checks aren't weighted equally in real-world risk — see our published scoring methodology for exactly how each signal is weighted. A single WebRTC or DNS leak that exposes your real IP is a more serious exposure than a middling fingerprint uniqueness score, even if the leak only costs you a few summary points. Read the individual card badges, not just the headline number — a 90/100 with one red "IP leak detected" card is a worse security posture than an 80/100 with only medium-severity fingerprint findings.

No. Every check — IP lookup aside, which necessarily contacts an external API to resolve your address — runs and scores entirely inside your browser. Your composite score, badges, and attribute values are computed in JavaScript on your device and are not transmitted to or stored on PrivacyTestLab's servers. You can verify this yourself by opening your browser's Network tab during a scan, or read our transparency page and privacy policy for the full data-handling policy.

No — that's expected behavior, not a leak. Safari's Private Browsing mode restricts or fully blocks IndexedDB and persistent localStorage by design as a privacy feature, so a "blocked" result there reflects Safari doing its job, not a misconfiguration on your end. The same check in a normal (non-private) Safari window, or in Chrome/Firefox private modes, which handle storage restrictions differently, may show a different result — this is one area where "worse-looking" isn't actually worse.

Re-run it any time you change something that could affect your exposure — connecting or disconnecting a VPN, switching browsers, installing or removing an extension, or updating your OS or browser version (which can change fingerprint signals like the WebGL renderer string). Outside of specific changes, a monthly check is reasonable for most people; daily re-scanning won't surface new information unless your setup has actually changed.

No — it measures exposure, not an active event. The fingerprint component estimates how rare your specific combination of signals is, which determines how easily a tracker *could* re-identify you if they tried. It doesn't mean any particular site is currently doing so. Run our dedicated Browser Fingerprint Test for the full 14-signal breakdown behind this card's score.

Most, but not all. WebRTC and DNS leaks are directly fixable with browser settings or extensions we link to on the dedicated test pages. Fingerprint-related signals (screen resolution, installed fonts, CPU thread count) are harder to fully eliminate without switching to a hardened browser like Brave or Tor, since some of those values are inherent to your actual hardware. The realistic goal for most people is reducing exposure meaningfully, not reaching a perfect, untraceable score.