Send Files Between Devices on Different Networks

By ShareDrop.org Engineering · Published 2026-09-12

Every nearby-share tool assumes the two devices are in the same room. The moment one of them is on a different network (a friend across town, a colleague in another office, your own laptop at work and phone at home), those tools have nothing to offer. This is the case that separates transfer methods into two groups, and it is worth understanding why before choosing.

Why “different networks” is the hard case

On one Wi-Fi network, devices have addresses that reach each other directly and can find each other by broadcasting. Across the internet, neither is true. Each device sits behind a router doing network address translation, which means it has no public address of its own and cannot be reached unless it opened the door first (how NAT works). And there is no broadcast on the internet; the two devices need a third party to introduce them.

Every cross-network method solves those two problems in one of three ways:

• Route everything through a server: cloud links, chat apps, email. The server is reachable, so both sides talk to it instead of to each other.
• Introduce the devices, then step aside: peer-to-peer with NAT traversal. A server helps them find each other; the data goes direct.
• Make a private network that spans the internet: a VPN or mesh network. Powerful, and far more setup than a file transfer deserves.

How a direct cross-network connection actually gets made

1. Both devices open a page and are matched by a short code. The rendezvous server learns that two devices want to connect — not what they will send.
2. Each device asks a STUN server what its public address looks like from outside (STUN explained).
3. The devices exchange those addresses through the rendezvous server and start sending packets to each other at the same time. On most home routers that opens both firewalls, “hole punching”, and the connection is direct.
4. If the routers refuse (symmetric NAT on one side, a corporate firewall, a mobile carrier), the devices fall back to a relay server that forwards their encrypted packets. The relay cannot read them (what it can see).

All of that takes about a second and is invisible except for one thing worth watching: the status badge. Internet direct means step 3 worked; Encrypted relay means step 4 was needed.

Step by step

1. Send the other person the address app.sharedrop.org, or nothing, if they have the ShareDrop.org app.
2. You tap Send, pick files, and read them the six-character short code (or share the invite link).
3. They tap Receive and type the code. Both of you see a “wants to connect” prompt; accept.
4. Compare the safety code over the call or chat you are already on. A match means nobody is in between (why).
5. The transfer runs; each file is checksum-verified on arrival.

What to expect from the speed

The ceiling is the sender's upload bandwidth. Home broadband is asymmetric: 300 Mbps down often means 20–50 Mbps up, so a 1 GB file takes three to seven minutes and no tool can change that — a cloud link pays the same upload, then adds a download. A relay adds latency, not a lower ceiling (diagnosing slow transfers). Mobile data uploads are often faster than home uploads, which surprises people.

A worked example, with the numbers

A phone on 5G in one city sends a 1.2 GB video to a laptop on home broadband in another. The phone gathers a reflexive candidate, but its carrier uses symmetric NAT; the laptop's home router is a port-restricted cone. The checks between them fail (why that pair cannot punch through), and about two seconds after the code was entered the badge settles on Encrypted relay. The phone's 5G upload measures 40 Mbps, so the transfer runs at about 5 MB/s and finishes in four minutes. The relay added around 40 ms of latency and changed the throughput not at all. Had both sides had IPv6 (many carriers do, this home ISP did not), the badge would have read Internet direct and the four minutes would have been the same four minutes.

The “both online” problem, practically

A direct transfer needs both people present, so treat it like a call: agree a time, and make sure both devices will stay awake. On a phone, the ShareDrop.org app keeps the screen on while a transfer runs; in a browser, a locked phone suspends the tab. On a laptop, close the lid and the transfer stops until it opens again: it resumes from the last verified chunk, but only when you come back. For a multi-hour transfer across a slow uplink, both devices plugged in and set not to sleep is the whole preparation.

Between your own devices in two places

If the two devices are both yours (a laptop at work, a desktop at home), a mesh VPN (Tailscale or similar) changes the picture: it gives each device a private address the other can always reach, so the connection is direct on that address from anywhere, and the badge reads LAN direct across the internet. Setting one up is more work than a single transfer deserves; for devices you connect weekly, it pays off (how VPNs of each kind affect transfers).

For whoever runs the network

If a transfer fails on an office or campus network and you can ask IT, the request is small: outbound UDP to port 3478 for STUN and TURN, or at least outbound TCP to 3478 and 443. Nothing inbound is needed and no port forwarding; every connection is started from inside. Most networks already allow this, because it is the same traffic video calls use.

Three things that look like network problems and are not

• The code expired. A short code is valid for minutes, not hours. If the other person takes a while to get to their device, make a new one when they are ready rather than sending it in advance.
• One side never accepted. The “wants to connect” prompt and the file-list prompt both need a tap. A phone face down on a desk with the prompt waiting looks exactly like a connection that will not come up.
• The sender locked the screen. In a browser, a locked phone suspends the tab before the transfer has begun; the receiver sees “connecting” indefinitely. Keep the sending screen on until the transfer is moving, or use the app, which keeps it awake.

Share the code by whatever channel you are already talking on. It is single-use and expires, so it is safe to say aloud or type into a chat; the safety code, compared after connecting, is what confirms nobody else used it first.

When both people are on mobile data

Two phones on cellular are both behind carrier-grade NAT, so expect Encrypted relay unless both carriers provide IPv6, in which case a direct IPv6 path usually wins. Either way the rate is the sender's upload, often 20–60 Mbps on 5G, and the data cost is the file size once at each end — the relay does not double it. If one phone can get onto Wi-Fi, do that on the sending side; upload is the half that matters.

When you should use a server instead

Peer-to-peer needs both devices online at the same time. That is the one condition it cannot relax, and it is exactly what a cloud link or an upload service is good at: the recipient collects the file whenever they are ready, and one link serves many people. If the other person is asleep in another time zone, send a link, accepting the stored copy and the account, and setting an expiry (the trade-offs). If they are on the phone with you right now, a direct transfer is faster, leaves nothing behind, and needs no account on either side.

When it will not connect at all

Rarely, a network blocks both the direct path and the relay, typically a corporate firewall that allows only web traffic to approved hosts, or a VPN that captures all traffic (VPN effects). Two fixes: move one device to a phone hotspot, which gives it an ordinary consumer connection; or, if the network is locked down on purpose, use whatever the organisation sanctions and do not fight it.