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.

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

SituationBest approach
Large file, same home or office Wi-FiLocalSend
Apple device to Apple device, quicklyAirDrop
Guest Wi-Fi at a cafe or venueCloud transfer (local transfer is blocked)
Recipient is remote or on another connectionCloud transfer
Recipient should download on their own scheduleCloud transfer
You need to convey a download URL out loudPASHIRU
You only need to move a URL, not a filePASHIRU

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.