Jaden Vo

Posted on Oct 26 Originally published at infinityme.dev

LocalSend: The Open-Source AirDrop Alternative and How It Moves Files Over Your LAN

#opensource #productivity #networking #tools

Getting a file from an iPhone to a Windows laptop, or from an Android phone to a Mac, still tends to end with someone emailing the file to themselves. AirDrop solves this only inside Apple's ecosystem. LocalSend is an open-source app that does the same job across platforms, and it does it without any server in the middle.

This post covers what it is, how it finds devices and moves files on a LAN, how to install it, and the few network issues that usually cause trouble.

What LocalSend is

LocalSend is a free app (Apache 2.0 license, about 95k stars on GitHub) for sending files and text between devices on the same local network. It is built with Flutter, with some Rust in the codebase, and runs on:

Windows 10 and later
macOS 11 Big Sur and later
Linux (on GNOME or KDE you need xdg-desktop-portal plus the matching -gtk or -kde backend)
Android 7.0 and later
iOS 13 and later (sharing from other apps needs iOS 14)
Fire OS

You don't create an account, nothing goes through a cloud relay, and the devices don't need internet access. They just need to be able to reach each other on the LAN. The latest release when I checked was v1.18.2 (August 2026).

How discovery works

The protocol is documented in its own repo, localsend/protocol (currently v2.2), and it's short enough to read in one sitting. The defaults are:

Multicast UDP on group 224.0.0.167, port 53317
HTTP(S) server on TCP port 53317

Both can be changed in settings. The spec says the multicast address sits in 224.0.0.0/24 because some Android devices reject other multicast groups.

When the app starts, it sends a small JSON announcement to the multicast group with its alias ("Nice Orange" and similar), device type, port, protocol (http or https), a fingerprint, and "announce": true. Other LocalSend instances that hear it reply by calling the sender directly:

POST /api/localsend/v2/register

If that HTTP call doesn't work, they can answer over multicast instead, with "announce": false so nobody replies to a reply.

Some networks drop multicast entirely. For that case the protocol has a fallback ("legacy mode") where the app sends the same /register request to every IP address on the local subnet. It's slower and noisier, but it works on networks where multicast doesn't.

The fingerprint is how a device recognizes itself and remembers peers. With encryption on, it's the SHA-256 hash of the device's TLS certificate. With encryption off, it's a random string.

How a transfer works

The default flow is an upload: the receiver runs the server, the sender acts as the client.

Prepare. The sender posts only metadata to /api/localsend/v2/prepare-upload: file names, sizes, MIME types, and optionally a SHA-256 hash and a preview. The receiver accepts all of the files, some of them, or none. If the receiver has a PIN set, it goes in as ?pin=....
Upload. The receiver returns a sessionId plus one token per accepted file. The sender then posts each file's raw bytes to /api/localsend/v2/upload?sessionId=...&fileId=...&token=.... These requests can run in parallel.
Verify or cancel. If a hash was sent, the receiver checks it and returns 422 on a mismatch. Either side can stop the session through /cancel.

Every device generates its own self-signed TLS certificate, so traffic is encrypted over HTTPS without a CA or any account system. Encryption can be switched off, which is one of the suggested fixes when transfers are slow.

There's also a reverse "download API" for when the other device doesn't have LocalSend. The sender starts a server and shares a URL like http://<sender-ip>:53317, which the receiver opens in a browser. This mode uses plain HTTP because browsers reject self-signed certificates. That's fine on your home network, but keep it in mind on shared Wi-Fi.

For debugging, GET /api/localsend/v2/info returns a device's alias, version and type.

Installing it

The README recommends installing from a store or package manager because the app doesn't update itself. Some common options:

# Windows
winget install LocalSend.LocalSend
# or: choco install localsend

# macOS
brew install --cask localsend

# Linux
flatpak install flathub org.localsend.localsend_app
# or: sudo snap install localsend
# Arch: yay -S localsend-bin

Mobile builds are on the Play Store, App Store, F-Droid and Amazon's store. EXE, portable ZIP, DMG, DEB, TAR, AppImage and APK files are on the GitHub releases page.

Two desktop options are worth knowing:

Portable mode: put an empty settings.json next to the executable and the app keeps its settings there. Handy for a USB stick.
Start in tray: launch with --hidden, for example localsend_app.exe --hidden.

The README also documents a terminal client, localsend-cli, built on the same protocol:

localsend-cli send --to 192.168.1.42 report.pdf
echo "hello" | localsend-cli send --to "Cute Tomato" --text -

Common problems

When a device doesn't show up, the cause is almost always the network, not the app.

Firewall: allow incoming TCP and UDP on 53317. With ufw on Linux that's sudo ufw allow 53317. With firewalld, add 53317/tcp and 53317/udp using --permanent, then run --reload.
AP / client isolation: guest Wi-Fi and some routers block device-to-device traffic. If isolation is on, LocalSend can't work on that network.
Windows "Public" network profile: switch the network to Private. Windows is stricter on public networks.
macOS/iOS Local Network permission: try turning it off and on again under Privacy settings.
VPNs: many block LAN traffic by default. Allow local traffic or turn the VPN off for the transfer.
Still can't see it? Send manually to the receiver's IP. If that works, add the device to favorites so the app contacts it directly.
Slow transfers: use 5 GHz Wi-Fi, or turn off encryption on both ends. Slow writes on Android are a known upstream issue.

Both devices have to be on the same network segment. LocalSend can't send over the internet. That's by design.

When to use it, and when not

LocalSend is a good choice for mixed-device homes and offices, for moving large phone videos to an editing PC, or anywhere you don't want files going through a cloud service.

It isn't the right tool for everything:

All-Apple setup? AirDrop is already built in.
Sending to someone in another city? You need a relay or cloud service, such as Magic Wormhole, a shared drive, or a self-hosted option.
Keeping folders in sync continuously? Syncthing does that. LocalSend handles one-off transfers.
Already scripting on a LAN? scp or rsync between machines with SSH will work fine. LocalSend helps most when phones are involved or when the person on the other end won't use a terminal.

Because the protocol is small and documented, you can also write your own client. Three endpoints are enough for a basic sender.

I keep a short guide with download links at infinityme.dev/repos/localsend, and I post short explainers on YouTube.

DEV Community