LocalSend

Last reviewed Aug 23, 2026 · 642 words

LocalSend is AirDrop for people whose devices don't all wear the same fruit logo: pick a file on any phone, tablet, or computer, tap the nearby device's name, done. No account, no cloud, no server to run — transfers travel directly between devices over your local network, encrypted, at LAN speed. It's the rare tool in this directory with nothing to deploy; the useful guide is knowing how it works, why it sometimes doesn't, and where its boundaries sit.

How it finds devices, and why that sometimes fails

LocalSend announces itself via UDP multicast on port 53317 and serves transfers over HTTPS on the same port, with devices generating their own certificates — that's the whole architecture. Both devices must be on the same network, and every "device not showing up" complaint reduces to one of four causes:

1. Firewall. Desktop firewalls (Windows Defender especially) must allow LocalSend on private networks — both TCP and UDP 53317. This is the number-one fix.
2. Client isolation. Guest Wi-Fi networks and many office/hotel networks deliberately block device-to-device traffic. Nothing LocalSend can do; switch networks or hotspot.
3. Different subnets. The laptop on Ethernet VLAN 10 can't multicast to the phone on Wi-Fi VLAN 20. Homelab people with segmented networks do this to themselves regularly — either allow mDNS/multicast across the relevant VLANs or use the fallback below.
4. Sleepy radios. Phones aggressively doze; open the app on both ends when a device won't appear.

When discovery fails but the network path exists, the manual fallback works every time: "Send → Link" produces a URL anyone on the network can open in a browser — which also makes LocalSend work with devices that don't have the app at all, guests included.

Settings worth thirty seconds

• Quick Save auto-accepts incoming files, which is what you want between your own devices and not what you want on a shared network where anyone can push files at you. Turn it on at home, off when travelling.
• Set the download directory on desktops so files land somewhere deliberate instead of the default folder you'll forget to check.
• Favourites pin your own devices to the top, which matters once the flat's worth of devices shows up.
• The desktop app sits happily in the tray at ~zero resource cost; on servers there's even a CLI, though at that point you're usually better served by real tooling.

Know where the design stops

LocalSend's constraint is its feature: same network, both ends present, one-shot transfers. It is not sync — if you want the phone's camera roll continuously mirrored to the NAS, that's Syncthing, which pays for its always-running daemon with automation LocalSend deliberately doesn't attempt. It is not remote — for "send this file to dad across the country", LocalSend has no relay; a shared Nextcloud link does that job, or joining both devices to a Tailscale network makes them "local" to each other and LocalSend works over the tunnel, a genuinely handy trick. And it is not a file server: nothing is stored, listed, or browsable. One tool per job is the point — the own-your-data toolkit mindset applied to the humble file transfer.

What I'd do

Install it on everything (it's on every platform store, plus winget/brew/flathub), allow it through desktop firewalls on private networks, enable Quick Save between your own devices, and teach the household that "how do I get this photo to the computer" now has a boring answer. Keep Syncthing for the flows that should happen automatically and LocalSend for the ones that shouldn't — the two-app combination quietly replaces AirDrop, USB sticks, and the ancient habit of emailing files to yourself.