LocalSend: local network file transfer without a server

The problem LocalSend actually solves

Moving a file between two devices you own is oddly hard. Email caps attachment size, chat apps re-encode images, cloud drives upload to a third party and then download again, and USB sticks require physical access and the right port. LocalSend targets exactly that gap: two devices on the same local network, one send, one receive, no account.

The README describes it as a cross-platform app that shares files and messages with nearby devices over the local network without an internet connection. The audience is anyone with a heterogeneous set of machines: an Android phone and a Windows laptop, an iPhone and a Mac, a Linux desktop and a tablet. The compatibility table spans Android 5.0, iOS 12.0, macOS 11 Big Sur, Windows 10 and Linux, which is the practical reason the project exists in this shape. A single-vendor tool would not need to be cross-platform; this one has no vendor to fall back on.

The second audience is people who object to the relay model on principle. With a cloud drive, the file leaves your network, is stored on hardware you do not control, and comes back. LocalSend keeps the bytes on the LAN, which changes the threat model rather than merely the speed.

How the REST API and HTTPS transport work

The README is explicit about the mechanism: LocalSend enables communication between devices using a REST API and HTTPS encryption. That is the whole architecture in one sentence, and it has consequences worth spelling out.

A REST API means each device runs an HTTP server and each transfer is a client request against it. Device discovery and the transfer itself therefore depend on the two machines being able to reach each other directly, which is why the setup section points at the firewall rather than at a login screen. The README states that in most cases LocalSend should work out of the box, and that if sending or receiving fails you may need to configure your firewall to allow LocalSend to communicate over your local network. That is the failure mode in one line: a blocked port looks like a broken app.

HTTPS means the payload is encrypted in transit rather than sent in the clear, which matters on shared networks such as a cafe or an office VLAN. It does not mean the receiving device is authenticated by a certificate authority you trust, and the README does not describe a trust-on-first-use flow or a pairing ceremony. Treat HTTPS here as transport encryption, not as a guarantee about who is on the other end.

The repository layout shows the implementation is split. There is a Dart application under app/, a Rust workspace declared in Cargo.toml with members cli, packages/core, packages/localsend_isolates/rust and server, and a packages/ directory alongside them. The Dart side is the app; the Rust side carries the CLI and server. The Cargo.toml comments also reveal a deliberate build trade-off: RSA key generation is described as bignum-heavy and roughly ten times slower unoptimized, so the rsa and num-bigint-dig crates are kept at opt-level 2 even in dev profiles to keep tests fast. That is a project that cares about its test loop.

Installing LocalSend and sending a first file

The README recommends downloading from an app store or a package manager, and gives the reason plainly: the app does not have an auto-update. That recommendation is not decoration. If you install from a loose binary, you own the upgrade path yourself.

On Windows, the README lists Winget, Scoop, Chocolatey, an EXE installer, a portable ZIP and the Microsoft Store. Each of those entries is a link to the distribution page for the package, and the README does not print an install command, so the exact invocation is whatever that package defines. Check the linked manifest before scripting it.

On macOS the README lists the App Store, Homebrew and a DMG installer, linking the Homebrew cask page for localsend. On Linux the channels are Flathub, Nixpkgs, Snap, AUR, and direct TAR, DEB and AppImage downloads, with Flathub linked for org.localsend.localsend_app. For Android the README points at the Play Store, F-Droid, a direct APK, and Amazon for Fire OS. For iOS it points at the App Store only.

The README does not give a single canonical install command for any platform, which is worth noticing. The install step is a click through to a store or package page, and the version you get depends on that channel's own release lag.

Once both devices have the app, the first real use is: put them on the same Wi-Fi network, open LocalSend on both, and pick the target device from the list that appears. The README does not document the exact discovery prompt or the confirmation dialog, so the honest description is that you select the other device and send. If nothing appears in the list, the README's own troubleshooting entry applies: check the firewall rules for the local network before assuming the app is at fault. Linux users have one extra dependency the compatibility table names explicitly: Gnome needs xdg-desktop-portal and xdg-desktop-portal-gtk, KDE needs xdg-desktop-portal and xdg-desktop-portal-kde. Missing those is a common reason a Linux install looks fine and then cannot pick files.

Where LocalSend is the wrong tool

LocalSend requires a shared local network. That single constraint rules out a lot of real scenarios. Sending a file to a friend in another city, to a colleague on a VPN with client isolation enabled, or to a server in a data centre are all outside what the README describes. There is no relay, no rendezvous server and no fallback path, because the absence of a server is the design.

Guest and corporate Wi-Fi is the sharper version of the same problem. Many access points enable client isolation, which prevents two devices on the same SSID from talking to each other at all. LocalSend will find nothing, and no amount of configuration inside the app will change that, because the block is upstream.

The second limitation is updates. The README states the app does not have an auto-update and recommends store or package-manager installs for that reason. A portable ZIP or a raw APK is a manual maintenance commitment. On a fleet of machines that is a real cost, not a footnote.

The third is the absence of a sync model. LocalSend is a send-and-receive tool. The README describes file and message transfer, not folder mirroring, versioning, conflict resolution or resumable queues. If you want two directories to stay identical, this is the wrong category of software.

Finally, the README carries a caution about an unofficial MSIX preview hosted at localsend.ob-buff.dev, stating that stability is not guaranteed and that custom code tweaks are listed on that site. That is a third-party build, not a project release. For anything beyond curiosity, use a listed channel.

LocalSend versus a cloud drive or Syncthing

The obvious alternative is a cloud drive, and the difference is architectural rather than a matter of taste. A cloud drive uploads to a server and downloads to the second device. LocalSend never leaves the LAN, so the transfer works with the router's uplink unplugged and with no account. The cost is that both endpoints must be online at the same moment and reachable from each other. A cloud drive tolerates asynchronous transfer; LocalSend does not.

A closer comparison is a continuous sync tool such as Syncthing, which also works peer to peer without a central server. The difference in approach is the unit of work. Syncthing maintains a folder as a replicated set, with hashing, conflict handling and a long-running daemon. LocalSend sends a selection of files once and is done. If your problem is "keep these two directories the same forever", a sync tool is the right shape. If your problem is "get this PDF onto that laptop now", LocalSend is the smaller, more predictable answer, and it does not keep a background process watching your disk.

The README's own framing is that LocalSend does not require an internet connection or third-party servers, unlike messaging apps that rely on external servers. That is the positioning. It is accurate as far as it goes, and it also tells you what you give up: the convenience of a server that is always reachable.

Licence, maintenance and the upgrade path

LocalSend is licensed under Apache-2.0, and the repository ships a LICENSE file at the top level. Apache-2.0 is a permissive licence with an explicit patent grant, which matters if you are considering redistributing the app or embedding parts of it. It is not a copyleft licence, so derivative work does not have to be released under the same terms. This is a description of the licence text, not legal advice; read LICENSE and the distribution notes in CONTRIBUTING.md before shipping anything.

The maintenance signal is the last push, on 2026-08-21, and the release cadence around it: v1.18.0 on 2026-08-10, v1.18.1 on 2026-08-12, v1.18.2 on 2026-08-21. Three releases inside a month is a project that is being worked on. The repository is not archived. Those are the only maintenance facts available here, and they say nothing about the quality of any individual release.

Upgrade cost depends entirely on how you installed it. Store and package-manager channels hand you a new version; a portable ZIP, a DEB, a TAR or a raw APK does not. The README's own advice to prefer stores and package managers is the cheapest way to keep that cost near zero. The compatibility table adds a second constraint: Windows 7 support ended at v1.15.4, so an old machine pins you to an old release. The CHANGELOG.md at the repository root is where you check what changed between the version you have and the one you are moving to.

Editorial conclusion

Adopt LocalSend if your devices already share a LAN and you want file transfer that does not route through someone else's server. Skip it if the two endpoints sit on different networks, or if you need an auditable sync protocol rather than a one-shot send. Before rolling it out, verify three things: that your firewall permits LocalSend on the local network, that you have a distribution channel with updates (the README states the app does not have an auto-update), and that your minimum OS versions meet the compatibility table, which starts at Android 5.0, iOS 12.0, macOS 11 Big Sur and Windows 10.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes