LocalSend transfers files and folders between nearby devices on the same local network. It can also carry plain text. The exchange needs no external transfer server or Internet connection.
A prepare request can describe multiple files, and the receiver can accept only selected items. Both devices normally run it, although a separate browser link can handle a receiver that does not have LocalSend installed.
Discovery and transfer use the local network
LocalSend announces its presence on the LAN. Other devices running it answer the announcement and appear as nearby receivers. The receiving device runs a local HTTP or HTTPS server for the exchange. No external transfer server carries the payload.
A host firewall or network policy can block local discovery and receiver traffic. When discovery fails, nearby devices do not appear as available receivers.
The receiver approves files before their data arrives
LocalSend sends file metadata in a prepare request before sending file data. The receiver can accept the entire request or reject it. A selective response accepts only chosen files. A Receive PIN adds a code that the sender must supply when the receiver requires one.
Each device creates its own TLS certificate for the normal encrypted LocalSend-to-LocalSend path. Approval controls which requested files move.
The browser fallback changes the transport
Reverse transfer exposes a local browser page for a device that does not have LocalSend installed. This path uses ordinary HTTP because browsers reject the self-signed certificate used by the local HTTPS exchange.
The browser link therefore lacks the encrypted transport of the regular LocalSend-to-LocalSend path. It still remains on the local network, but it is not equivalent to the certificate-based connection between two LocalSend installations.
Updates come through the installation channel
There is no internal automatic updater. The project directs updates through the application store or package manager used for installation. An installed copy can therefore remain unchanged until that channel supplies and applies another package.
Official Windows files may show SignPath Foundation as the signing publisher because the project uses SignPath Foundation for code signing. That publisher label belongs to the project’s signing route rather than to an unrelated transfer service.
A folder becomes a list of relative file paths
It handles a folder by enumerating its files recursively. Each transferred file keeps a path relative to the selected folder, so nested material can reach the receiver without flattening every name into one directory. An empty folder has no file entry to carry and therefore has no representation in this transfer model.
Plain text enters the request as a file item
LocalSend encodes submitted plain text as UTF-8. It creates a .txt CrossFile entry in the normal transfer request. The receiver handles that entry through the same approval workflow used for file data.
