LocalSend Under the Hood: LAN Discovery, Token-Based Transfer, and a Default-HTTP Gotcha

I wanted to transfer a few photos and some files from my phone to my computer. Both were on the same Wi-Fi network, and I expected this to be simple, but finding the right tool was a bit of a challenge.

If both devices are Apple devices, AirDrop is straightforward. But if either the phone or the computer runs a different OS, that option is out. Sending the files to myself and then downloading them on the computer works, but it's a detour when both devices are right there. I wanted a tool that could transfer files directly over the same network without extra steps.

Following that requirement, I found LocalSend. It's dedicated to LAN file transfer: images, videos, documents, and more. Clients cover Android, iOS, Windows, macOS, and Linux. I tested its Web client with a Mac and an iPhone, opening the web page on both, finding each other, and sending files. It worked smoothly, and I've included actual screenshots below.

After testing, I got curious. Devices appearing in the list seems natural, but how do they actually find each other? From which side does the file connection start, and what happens when the receiver taps accept? So I dug into the project's source code, and this article is the result.

The version I looked at is v1.18.2, focusing on the native client's v2 direct transfer over LAN and the separate browser-share entry in the app. The Web client test is covered separately later.

Devices appear in the list after a round-trip

The address of a computer on a home network can change. If you had to check the address every time and type it manually, it would be tedious. LocalSend's native app proactively announces its name and connection method to nearby devices, letting other apps on the same LAN discover it.

The receiving device also attempts to connect back to confirm the path works. When encrypted connections are used, it also checks whether the peer's certificate matches the information announced earlier. Only after confirmation does the device appear in the list. The name is mainly for you to recognize the device; it doesn't prove who owns it.

Breaking this down: a name in the list already involves a round-trip behind the scenes.

So even on the same Wi-Fi, devices still need to confirm they can reach each other. If you can't find each other, check the common issues at the end.

Ask before sending, then transfer

Suppose the phone sees the computer and you're about to send two photos and one video. The phone sends a file manifest to the computer first. The computer can decide which files to accept before the file content arrives. If a receive PIN is set, it checks that as well.

After the receiver accepts, it assigns a transfer ID to the batch and issues a temporary credential for each approved file. The phone uses those credentials to send the corresponding files. This links "the file you agreed to receive" to the subsequent upload.

In the full flow, two kinds of waiting are distinct: first you wait for the device to respond, then you wait for the receiver to confirm.

When the file arrives, the computer checks the sender, the batch transfer ID, and whether the file has already begun. Duplicate upload requests for the same file are blocked. If both sides provide and enable integrity checks, the computer also verifies that the received content matches what the sender declared.

Encrypted connections, temporary credentials, and content checks solve different problems. Encryption protects the transfer in transit; credentials limit which files are allowed for this upload; content checks detect whether a file changed.

v1.18.2 has one usage limitation. The receiver handles only one sender at a time; waiting for user confirmation counts as occupied. Different files in the same batch can transfer concurrently, but another device has to wait for the previous batch to finish. This matters little for occasional home transfers, but when multiple people take turns sending materials to one computer, they queue up.

Use the app, or a web page? Know the entry points

LocalSend has several easy-to-confuse modes. Both sides installing the app, the app generating a browser share link, and both sides opening the Web client directly are three distinct entry points. The phone screenshots later show the third type.

Choosing an entry based on the devices and scenario first helps you understand the differences below.

When both sides can install the app, use the app to transfer directly. When the other party is just picking up a file temporarily, the sender can enable browser share from the app and give the other party a LAN link. They open the link and download, skipping installation.

Here's a default setting to watch. I checked the v1.18.2 source code and test cases: the in-app browser share uses HTTP by default, meaning the connection itself is not encrypted. It offers an encryption toggle; when enabled, it uses HTTPS, but browsers may warn about an untrusted certificate, requiring extra handling.

Setting a receive PIN can limit who starts a download, but it doesn't automatically encrypt the HTTP connection. Looking at whether the address starts with http:// or https:// before sharing is more useful than just checking whether it can be scanned to open. I verified this against source and test cases; I didn't capture real network traffic between two devices.

The Web client provided on the official site is another entry. The test below only covers its operation experience; you can't apply the default settings of the in-app share link to it.

Web client test on Mac and phone

These actual screenshots are from the LocalSend Web client: a Mac and an iPhone on the same Wi-Fi, both opening the web page in a browser. It uses a different connection method from the native app described earlier; here we focus on the actual operation.

When the Mac opens the page first, the device list is empty, and the page prompts you to open LocalSend on another device.

After the phone opens the page, the Mac's list shows the phone as "Gorgeous Coconut", labeled iOS · Safari.

The phone also sees the Mac as "Energetic Cherry", labeled macOS · Chrome. Tapping the device card offers three input sources: photo library, camera, or file picker. After selecting content, it enters "Sending files" state. The screenshots from left to right show discovering the Mac, selecting files, and send progress; the last one is the start of the send, with progress still at 0 B.

Common issues

The list below is compiled from the official troubleshooting documentation, mainly for the installed app. Keep both apps open and try a small file first; the web version uses a different discovery mechanism, so not all settings apply directly.

Same Wi-Fi, why can't I find each other?

Check item	Possible cause and solution
Router device isolation	Guest networks or "AP isolation" block device-to-device traffic. On a trusted network you manage, check and turn off isolation.
Windows network type	Public network access restrictions can be stricter. On a trusted home network, set the connection to "Private network" and allow LocalSend through the firewall. The default port is 53317; allow both TCP and UDP.
Mac/iPhone local network permission	Allow LocalSend in System Settings > Privacy & Security > Local Network. If it's already allowed but still failing, try turning it off and on, then restart the app. The exact menu name may vary by OS version.
VPN or proxy interference	Pause both ends' proxy tools first, or allow LAN access and bypass local addresses in the proxy tool. Don't assume all proxy modes block connections.
Auto-discovery fails	Try "Manual send" and enter the receiver's LAN IP address. If it connects, you can add to favorites for later direct probing; if not, continue checking network isolation and firewall. Manual IP entry cannot bypass access restrictions.

In my Web client test, I encountered a situation where one end had a proxy on and neither side could see the other; after turning off proxy on both ends, it recovered. Discovery and connection need a round-trip; if the network route or access rules on one end change, the other end may not get a response, so both sides may see nothing. This only confirms the proxy affected this connection; pinpointing the exact step requires network logs.

Also, 2.4 GHz and 5 GHz are different Wi-Fi bands, but that doesn't necessarily mean devices can't communicate. If the router forwards correctly, both sides can still connect; you need to check whether they're placed on mutually isolated networks.

Can transfer files, but why slow?

Try moving closer to the router and using 5 GHz Wi-Fi in a spot with good signal. 2.4 GHz is more susceptible to interference from surrounding devices, but 5 GHz also suffers from distance and walls; don't judge speed by band name alone.

The official docs also list a comparison method: turn off transfer encryption on both sides and see if speed improves. Encryption adds processing overhead, but it may not be the cause of your slowness. Do this comparison only on a trusted network with non-sensitive test files, then restore encryption. Don't interpret disabling encryption as a guaranteed speed boost.

If Android is slow at receiving, there's an official note about a file read/write performance issue, linked to the saf_stream performance discussion. In short, time may be spent writing received data to the phone, not entirely on Wi-Fi speed. However, this issue has been marked done and closed; whether it still affects your installed LocalSend version depends on the components and actual behavior. Try updating the app, then compare the same file with another receiving device to narrow down the scope.

If the two devices are on different networks, or you want the other party to pick up later, a cloud drive or other sharing method that temporarily stores files is more suitable. LocalSend fits when both devices are present and the network can reach each other; pick the files and send directly.