Pasted candidates and SDP are analyzed locally. The live gathering test, when you start it, contacts only the STUN servers listed on the page, directly from your browser.
Pick the STUN servers to contact, then press Start gathering. A baseline gathering with no STUN server always runs too, so you can see the plain host candidates on their own.
Related tools
- Browser Privacy CheckSee what your browser leaks: fingerprint surface, exposed APIs, and privacy signal irony, all analyzed on your device.
- URL ParserBreak a URL into scheme, host, port, path, query parameters, and fragment, with percent-encoding decoded on every field.
- User-Agent ParserDecode a raw User-Agent string into browser name and version, rendering engine, operating system, and device type.
- DNS LookupQuery A, AAAA, MX, TXT, and other DNS records over DNS-over-HTTPS through Cloudflare, Google, or dns.sb, no server needed.
- HTTP Header InspectorSee exactly which HTTP request headers your browser sends, with a plain English explanation for User-Agent, Sec-CH-UA, and more.
- Subnet CalculatorCIDR math, address ranges, splitting, and supernetting for IPv4 and IPv6.
What it does
Parses ICE candidate lines, whether pasted individually, embedded in a full SDP blob, or supplied as the JSON array a live gathering test produces. Each candidate is decoded into its foundation, component, transport, priority, address, port, and type, and its address is classified as private IPv4, public IPv4, an IPv6 scope, or an mDNS-hidden hostname. From the full set of candidates it reports hedged verdicts on STUN reachability, TURN relay availability, and whether the mapping pattern across STUN servers hints at a symmetric NAT.
How to use it
Paste one or more candidate lines (with or without the candidate: or a=candidate: prefix), a full SDP offer or answer, or the JSON array produced by a live ICE gathering run. Each candidate appears as its own row with a compact type, protocol, address, and classification, followed by rows for ICE ufrag count and DTLS fingerprint presence when the input was an SDP, and then the interpreted NAT and reachability verdicts.
Why this one
Reading raw ICE candidates by eye means decoding a dense space-separated line and remembering which RFC 1918 ranges and IPv6 scopes matter. This does that decoding and classification instantly and explains what a symmetric NAT mapping or a missing relay candidate actually means. Pasted candidates and SDP are parsed entirely locally and never sent anywhere; only the optional live gathering test contacts the STUN servers you pick (Google, Cloudflare, and Twilio's public STUN servers are selected by default) directly from your browser, the same way any WebRTC page would.
FAQ
- Why do my candidates show something.local instead of my real IP?
- That is mDNS obfuscation. Chrome, Firefox, and Safari all hide a device's real local network IP behind a randomly generated .local hostname on host candidates, so a web page cannot fingerprint your LAN address just by starting a WebRTC connection. Only another device on the same local network, doing mDNS resolution, can turn that name back into an IP.
- What does srflx vs relay mean?
- srflx (server-reflexive) is the public ip:port a STUN server observed for your connection: it proves outbound UDP reached the server, but the two peers still connect directly, address to address. relay is an address allocated on a TURN server that actually forwards traffic between both peers, used when direct connection fails, typically behind a symmetric NAT or a restrictive firewall.
- Does this page see my IP?
- No. Pasted candidates and SDP are parsed and classified entirely in your browser. If you run the live gathering test, your browser talks directly to the STUN server you pick from the list on this page; this site is never in that path and never receives your address.
Keyboard shortcuts: press ? anywhere on this page to see them.