How Two Devices on Different Networks Actually Find a Path to Each Other
An earlier post on this blog explained why a browser-based transfer needs an internet connection at all, even when two devices are sitting side by side. This one goes a level deeper: once two devices are on completely different networks — one on home Wi-Fi, one on mobile data, possibly on opposite sides of a country — what actually has to happen for them to open a direct connection to each other?
Every network hides its devices behind an address
A home router, a mobile carrier's network, a coffee shop's Wi-Fi — each one puts every device behind a layer of network address translation, or NAT. That means a device's real, routable address on the wider internet usually isn't directly visible from outside its own network; the router or carrier is quietly standing in for it. This is normal, sensible network design, and it's the reason two devices can't just dial each other's raw address directly.
Each device gathers a list of possible paths
This is what STUN is for. Each device sends a quick request to a STUN server and asks, in effect, "what does the outside world see as my address?" The answer becomes a candidate — one of possibly several, since a device might have a local network address, a NAT-mapped public-facing address, and sometimes more than one of each if it has multiple network interfaces. Neither device knows yet which of these, if any, will actually work.
Trading candidate lists through the signaling server
Through the same signaling handshake that gets two devices talking in the first place, they exchange these candidate lists — this is the "ICE candidates" portion of the offer/answer exchange WebRTC handles under the hood. At this point neither device has committed to a path; they're just comparing notes on what might be reachable, the way two people meeting at an unfamiliar venue might each list a few possible entrances before picking one.
Trying pairs until one connects
The browsers then attempt to open a real connection using different combinations of those candidates — generally trying the most direct-looking options first — until one pair actually succeeds. This whole process runs automatically, in the background, and typically resolves in well under a second. Nobody has to pick a candidate manually; it's closer to two phones dialing several possible numbers at once and staying on whichever line actually picks up.
When every direct pair fails
Some NAT configurations — common on stricter mobile carriers, or a locked-down corporate network — block every direct combination outright, no matter how many candidates get tried. That's the fallback covered elsewhere on this blog: a TURN server. It isn't a candidate pair between the two devices at all; it's a third point both sides can reach, relaying the encrypted stream between them when a direct path genuinely doesn't exist.
Why this all happens invisibly
From the outside, pairing two devices on completely unrelated networks looks instant — a QR scan, a brief pause, then connected. Everything described above — the candidate gathering, the exchange, the trial-and-error connection attempts — is what fills that brief pause. It's a genuinely more involved process than dialing a phone number, working around real constraints (NAT, firewalls, mismatched networks) that a phone call was never designed to deal with, done automatically enough that it never needs to be visible at all.
Related reading
P2P Transfer How WebRTC Makes Browser-to-Browser File Transfer Possible Why QR Codes Became the Default Way to Pair Devices