MyIP.dogChoose the scope of your privacy scan
A privacy scan is most useful when you know which question each observation can answer. This page brings selected connection, browser and target-address checks into one report. You choose the components, review their destinations and start them deliberately. A finished report is a set of observations, not a certificate of anonymity or a judgment about the person using an address.
Begin your privacy scan with a specific task. You might want to compare HTTP and WebRTC address observations, inspect browser preferences, investigate a public PTR name or review mail-list evidence. Select only the relevant components. The tool does not start measurements because you opened the page, and it does not silently add a port sweep to another check.
There are two distinct contexts in this privacy scan. Browser checks describe the browser and connection making the requests. Target checks describe the public IP entered in the form. One run can include both, but the target might be a server you administer rather than your own connection. Their results remain separate so that one context cannot be mistaken for the other.
For target checks, the privacy scan accepts one public IPv4 or IPv6 address. Hostnames, URLs, paths and port suffixes are rejected. The Use connection IP button makes a fresh request to this site and fills the form; it does not grant permission to probe that address. The form clears the TCP permission confirmation whenever you change the target or refill it.
Consent and destinations in a privacy scan
Each privacy scan option names its source before you select it. The site-IP option contacts this website. Address-family observations contact the IPv4 and IPv6 ipify endpoints directly. WebRTC gathering uses the browser's ICE API and Cloudflare STUN. Those services can observe the request or connection metadata relevant to their protocols; this tool does not make outbound communication invisible to its destination.
Browser signals in this privacy scan are read locally. Optional Canvas and WebGL collection requires an additional choice and does not upload the measurements. Reverse DNS and mail-list options send target-related questions through this site to Google Public DNS. The interface identifies these distinct flows because local inspection, a resolver query and a connection attempt have different implications.
TCP checks require a separate permission confirmation in the privacy scan. Use them only for an address you own, administer or have explicit authorization to test. A VPN exit, shared gateway or carrier address may be operated by someone else. The interface does not infer authority from the fact that an address appeared in your browser or in a public registry.
Read a privacy scan one component at a time
The privacy scan shows a state for every component, including those you did not select. Not selected means it did not run. Running means work is still pending. Complete observation means that component returned the evidence expected within its defined scope. In these results, complete describes the measurement; it never means that the connection passed a universal privacy test.
Partial evidence is a normal privacy scan outcome. An IPv4 echo can work while IPv6 is unavailable, a browser API can be blocked, or some TCP attempts can reach a runtime restriction. Review the affected rows instead of treating the whole run as either a success or failure. One unavailable source does not erase useful evidence returned by another source.
A timeout in the privacy scan establishes that an observation did not finish within its allowed wait. It does not establish why the response was missing. Network filtering, routing, provider availability and browser settings can produce similar symptoms. The report leaves that uncertainty visible rather than converting an unanswered request into a green result.
Site and address-family observations
The site-IP privacy scan component records the address this website observes for its request, together with the address family and observation time. That is a source-specific network observation. It does not necessarily identify a particular device behind a shared connection, and the report does not turn it into an exact household location or account identity.
The address-family privacy scan component makes separate IPv4 and IPv6 HTTP requests to ipify. Each successful response describes the address visible on that path. If the IPv6 endpoint cannot be reached, the result reports no IPv6 observation. That result alone does not prove that every application, interface or destination on the device lacks IPv6 access.
Differences between sources can be useful in a privacy scan, but they need context. Different protocols, destination policies, address families and network routes can expose different exits. Record the source and time before investigating a mismatch. The tool does not automatically label every difference as a VPN failure, malicious proxy or compromised device.
WebRTC evidence and its limits
The WebRTC privacy scan component creates a temporary peer connection for candidate gathering. It requests no camera or microphone tracks, establishes no remote peer session and closes its resources when collection ends. The browser peer-connection API exposes the candidate-gathering lifecycle. This component uses that lifecycle as diagnostic evidence, without recording a call or sending media.
For comparisons, the privacy scan uses only public non-relay candidates and matching-family HTTP observations from the same run. A manually entered target address is never used as a reference for this browser. If no matching-family reference exists, the privacy scan marks that comparison as unperformed; a server you typed into the form cannot stand in for a missing browser measurement.
An agreement in the privacy scan means the addresses available for that comparison agree. It does not prove that no other interface or application can use another route. A difference remains a difference to investigate, while timeouts, errors, truncated gathering or missing references keep the privacy scan inconclusive. TURN relay addresses are excluded from this comparison because their purpose differs from an ordinary local exit.
Some browsers expose mDNS names instead of local numeric addresses. The privacy scan does not resolve those names or interpret them as public addresses. Detailed copied reports omit the mDNS identifiers. Candidate counts can still help explain an inconclusive privacy scan without exporting an unnecessary local hostname or raw session description.
Browser signals and optional graphics
The browser portion of the privacy scan reads supported configuration, screen and preference values. A field can be available, unavailable, blocked or deliberately not run. None of those states independently determines whether you are trackable. The privacy scan has no representative population dataset from which to calculate a uniqueness percentage or a reliable probability of identification.
Global Privacy Control, where exposed, is one browser-reported preference in the privacy scan. Its presence does not measure whether every destination honors it. The API description explains the signal itself. The privacy scan likewise distinguishes a reported cookie capability or legacy Do Not Track value from a direct test of third-party tracking behavior.
Optional graphics observations add a fixed Canvas sample and supported WebGL fields to the privacy scan. Browsers may block, reduce, change or add noise to those values. The collection stays local and is explicitly selected. A privacy scan does not bypass those protections, request high-entropy client hints or combine the resulting values into a persistent visitor identifier.
Target reverse DNS and mail-list evidence
The reverse DNS privacy scan component asks for PTR evidence concerning the entered address. The response includes its resolver, time, response code and returned records. A name can suggest an operator's naming convention, but it is not verified identity, physical location or proof of a service. A privacy scan with no PTR answer is not automatically an indication of a problem.
The mail-list privacy scan component uses two named IPv4 sources: SpamCop SCBL and the Passive Spam Block List. It retains positive and negative control evidence before interpreting a response. These sources concern their own mail-list policies. The privacy scan does not describe them as a complete malware, fraud, browsing-history or personal-reputation database.
IPv6 is unsupported by the two mail-list integrations in this privacy scan. An unsupported result is distinct from not listed. A failed control, unexpected answer or resolver failure also prevents an interpretable result. Review the mail blacklist checker for the source-specific method and limitations; the privacy scan preserves that distinction when presenting the combined report.
Deliberately selected TCP checks
The TCP component of the privacy scan uses the existing fixed common-port preset: 22, 25, 80, 443, 3389 and 8080. Attempts originate at this site's server, one at a time, with existing shared budgets and execution limits. The privacy scan sends no application payload and does not search all ports, attempt logins, detect software versions or run an exploit.
A TCP connection that opens in the privacy scan shows that one connection succeeded from that probe path at that time. The port's common label is not a confirmed application identity. A refused connection, timeout, unreachable route, platform restriction or unavailable measurement has a different meaning. The privacy scan retains those outcomes instead of merging every non-open result into “closed.”
The probe's geographic location is not measured by this privacy scan. Results therefore do not establish universal reachability from every network. Cloudflare runtime restrictions can also prevent a permitted target from being tested. The port checker explains the transport scope; a privacy scan does not override its destination restrictions, quotas or uncertainty.
Stop, clear and share a privacy scan
A privacy scan has a 45-second overall deadline, with shorter component-specific limits. WebRTC gathering stops after twelve seconds, and the TCP preset has its existing bounded transaction window. No automatic retry starts another measurement. When an individual component fails, the privacy scan keeps the other selected components independent and preserves their recorded evidence.
Stop cancels pending privacy scan work while preserving observations already returned. A partly received TCP stream remains incomplete. Clear removes results, target input, selections and permission confirmation. Hiding the tab, leaving the page or navigating away also clears the privacy scan. A delayed module download or response must not recreate a discarded report or start an unrequested follow-up.
The default copied privacy scan report is a summary of coverage, states, times and counts. It omits target IPs, observed addresses, PTR names and browser values. Selecting detailed export is a separate action because those details may be sensitive in combination. Review a privacy scan report and its destination before sharing it with a support team or posting it publicly.
Detailed privacy scan reports can contain the entered target, observed public or local numeric addresses, DNS records, browser configuration and optional graphics values. They still omit raw session descriptions and mDNS identifiers. The privacy scan does not save reports in local or session storage, put inputs in page URLs or add report contents to analytics events. Clipboard retention is controlled separately by your browser and operating system.
Understand what remains outside the privacy scan
This privacy scan does not currently collect authoritative DNS resolver-exposure evidence or classify VPN, proxy, Tor and hosting usage. It does not provide remote-IP city geolocation, search breach records or inspect a complete TLS certificate chain. These are visible coverage gaps, even when the selected privacy scan components finish; unavailable data is not replaced with a guessed classification.
The privacy scan also cannot inspect every process, extension, device interface or application on your network. It does not determine whether a provider logs traffic, whether an account reuses credentials or whether a remote organization complies with a privacy law. Such questions require different evidence. Keep the privacy scan's observed sources separate from broader conclusions about personal safety or anonymity.
Questions about the privacy scan
Can I run only local checks? Yes. Select Browser signals and leave the network and target components unchecked. Optional graphics remain a separate choice. The privacy scan then collects that local evidence without starting its IP echo, STUN, DNSBL, PTR or TCP measurements. Ordinary page delivery and site analytics remain separate, as described in the privacy policy.
Should I change my network settings after one result? First confirm what the privacy scan actually observed, its source and its limits. Repeat a relevant component deliberately when conditions are stable, or use the linked specialist tool to understand the result. This page organizes evidence; it does not prescribe a universal configuration change based on a missing field or a single unsuccessful probe.