What local transfer means
When most people send a file, it goes through the cloud. You upload it to WeTransfer, drop it in Google Drive and share a link, or attach it to an email. In every case the file is parked on a server somewhere on the internet, and the recipient pulls it down from there.
Local transfer skips that trip. The sending device and the receiving device connect directly inside the same network and hand the file over. There is no upload-then-download round trip, and no copy of the file left sitting on someone else's server.
Apple's AirDrop and Android's Quick Share are the familiar examples, but both are largely confined to their own ecosystems. Apps like LocalSend exist to do the same thing across operating systems.
What LocalSend is
LocalSend is a free app for sending files and text directly between devices on the same network. It is developed in the open and describes itself as a cross-platform alternative to AirDrop.
- Platforms: Windows, macOS, Linux, Android, iOS
- Price: free and open source
- Account: none required
- Internet: not required — the same LAN is enough
- Size limit: none imposed by the app; in practice bounded by network speed and free space
- Retention: not applicable, since nothing is stored on a server
Using it means opening the app on both devices. Devices on the same network appear in a list, you pick one, and you send. There is no pairing step and no account to link.
Encryption and PIN
Transfers are encrypted over HTTPS. The certificates are self-signed and generated by each device on the fly — no external certificate authority is involved. This protects traffic inside the local network; it serves a different purpose than a public server's certificate.
You can also require a PIN before a transfer is accepted. In an office or classroom where dozens of devices share a network, that is what stops a file from going to — or arriving from — the wrong machine.
"Share via link" for people without the app
For recipients who do not have LocalSend installed, there is a "Share via link" option. The sender generates a download URL and the recipient opens it in a browser to get the file.
The URL it produces, though, looks like http://192.168.x.x:53317/... — a local IP address plus a port number. That format creates a problem of its own, which we will come back to.
Why local transfer is fast
A cloud transfer pushes twice the file's size across your connection: once up from the sender, once down to the recipient. On top of that, most consumer connections are asymmetric, with upload speeds well below download speeds — so on a large file, the upload is where most of the waiting happens.
Local transfer moves the data across the LAN once. Over Ethernet or 5 GHz Wi-Fi, that is frequently an order of magnitude faster than the internet link. On a 1 GB video the difference is hard to miss.
There is a secondary benefit: retention stops mattering. Cloud transfer services expire files after three days, seven days, or whatever the plan allows, and a recipient who forgets to download in time means doing it all again. With local transfer, once the transfer finishes, it is finished.
The "same network" assumption
That is the upside. In practice, nearly every failure comes back to a single cause: both devices must be on the same network, and that network must let them talk to each other directly. Here is where that stops being true.
1. Client isolation on guest Wi-Fi
Wi-Fi at cafes, hotels, coworking spaces, and event venues very often has client isolation (AP isolation) turned on. Devices connected to the same access point cannot reach each other; only traffic out to the internet is allowed.
That setting is the correct call from a security standpoint — letting strangers' devices see each other on a shared network would be worse. It also means local transfer on public Wi-Fi is not something to plan around. It is blocked by design.
2. Corporate and school networks
Device discovery relies on multicast and broadcast traffic within the network. Managed networks frequently filter that traffic, or split departments into separate VLANs, so the other device simply never shows up in the list.
Entering an IP address manually sometimes gets around it. But on a managed machine you often cannot install the app in the first place, which ends the discussion.
3. Different connections
They are on home Wi-Fi and you are on cellular. Or one of you is on a corporate network and the other is out of the office. There is no shared network, so local transfer is out. Crossing networks was never what this design was for.
4. Both people have to be present at once
Cloud transfer is asynchronous: the sender uploads, and the recipient collects whenever suits them. Local transfer is synchronous — both devices need to be awake with the app open at the same moment. It always involves some version of "I'm sending it now, open the app."
Comparing the approaches
| LocalSend | AirDrop | Quick Share | Cloud transfer | PASHIRU | |
|---|---|---|---|---|---|
| What it moves | Files and text | Files | Files | Files | URLs and text (up to 2,000 chars) |
| Same network required | Yes | Proximity (Wi-Fi/BT) | Proximity (Wi-Fi/BT) | No | No |
| OS restrictions | None | Apple only | Android/Windows | None | None (browser only) |
| Recipient needs | The app (or a share link) |
Built into OS | Built into OS | A way to receive the URL | To hear 6 digits |
| Stored on a third-party server | No | No | No | Yes | URL only, temporarily |
| Works asynchronously | No | No | No | Yes | Yes (within its expiry) |
| Can be conveyed verbally | No (IP:port) | — | — | No (long URL) | Yes (6 digits) |
The part that remains: handing over the link
That last row is the point worth dwelling on.
Local or cloud, the step that usually survives is telling the other person the URL. LocalSend's share link — something like http://192.168.1.24:53317/... — is a clean illustration. Reading that aloud to someone in the same room is not realistic. An IP address, a colon, a five-digit port, then a path. Every attempt produces a "sorry, say that again."
So you open a chat app or an email to send the link instead. The file avoided the cloud, but the URL describing it went through the cloud anyway. And if you do not have the person's contact details, even that is unavailable.
PASHIRU solves only this. Paste a URL, get six digits, and the recipient enters those digits at pashiru.com to open the same URL. "Three nine three, nine three nine" is short enough to say out loud and short enough to hear correctly. No contact exchange, no app install.
The two do not compete. LocalSend carries the file directly; PASHIRU carries the link by voice.
Choosing by situation
| Situation | Best approach |
|---|---|
| Large file, same home or office Wi-Fi | LocalSend |
| Apple device to Apple device, quickly | AirDrop |
| Guest Wi-Fi at a cafe or venue | Cloud transfer (local transfer is blocked) |
| Recipient is remote or on another connection | Cloud transfer |
| Recipient should download on their own schedule | Cloud transfer |
| You need to convey a download URL out loud | PASHIRU |
| You only need to move a URL, not a file | PASHIRU |
Summary
When the conditions line up, a local transfer app like LocalSend is the fastest option available. No cloud, no size cap, no expiry to worry about, and no copy of your file on someone else's server. Free and cross-platform on top of that, it is worth having installed before you need it.
The assumption it rests on — same network, devices allowed to reach each other — breaks surprisingly easily on public Wi-Fi and managed networks. Local and cloud transfer are not better and worse; they answer to different preconditions.
And with either one, delivering the URL to the other person remains a separate problem. For choosing between transfer services themselves, see Is WeTransfer Still the Go-To? A Practical Comparison of File Sharing Services.