Transfer Files to Linux from Any Device (Phone, Mac or Windows)

By ShareDrop.org Engineering · Published 2026-09-05

Linux desktops are excluded from both walled gardens: no AirDrop, no Quick Share, and phone vendors' own transfer apps rarely ship a Linux build. The good news is that the Linux world has produced tools that are, in several cases, better than what the big platforms offer, and that a plain browser works as a client when you do not want to install anything. Here is the honest ranking.

LocalSend: install it if you can

Open source, packaged for every major distribution (Flatpak, AppImage, Snap, AUR, and native .deb/.rpm), with apps for Android, iOS, Windows and macOS. Devices on the same Wi-Fi discover each other and transfer directly. It is fast, keeps original files, and needs no account. Its limits are the same as every LAN tool: everyone must install it, and it cannot cross networks. For a Linux desktop and a phone at home, it is the best option, full stop.

KDE Connect / GSConnect: the phone-to-desktop integration

KDE Connect (and its GNOME Shell port, GSConnect) pairs an Android phone with a Linux desktop once and then does far more than file transfer: shared clipboard, notification mirroring, remote input, media controls. File sending is a right-click away on either side. There is an iOS app, with a narrower feature set. Again LAN-only, again worth it if the phone and desktop live together.

SSH tools: for the people who already have SSH

If the Linux machine runs an SSH server, scp and rsync from another Linux or Mac (or Windows with OpenSSH, which is built in) move anything, resume interrupted copies, and preserve permissions and structure. Phone clients exist but are awkward for picking photos. This is the right tool for admins and the wrong tool to explain to a relative.

A browser link: when nothing is installed, or the other device is far away

Every Linux desktop has Firefox or Chromium, and both speak WebRTC. That is the whole requirement.

1. On the Linux machine, open app.sharedrop.org and click Receive.
2. On the sending device (phone, Mac, Windows, another Linux box), open the same address (or the ShareDrop.org mobile app), tap Send, pick files, and scan or type the short code.
3. Approve both sides; compare the safety code once.

On the same network the link is direct and router-bound. Across networks it goes direct where the routers allow and through an encrypted relay where they do not, and the page says which (what changes). Nothing to install on the Linux side, no account, and the file is SHA-256-verified on arrival.

One Linux-specific caveat: Chromium on Linux supports the File System Access API, so it can write large files and folders straight to disk as they arrive. Firefox does not, so it assembles each file in memory and is capped at 512 MB per file (why). For a multi-gigabyte transfer, receive in Chromium.

Receiving in a Linux browser: the details

Chromium, Chrome, Brave and Edge on Linux support the File System Access API, so a transfer can ask once for a destination folder and then write every file, and subfolders, straight to disk as it arrives. Firefox does not; it hands each file to its download manager into ~/Downloads, assembling it in memory first, which is where the 512 MB per-file cap comes from. Two packaging quirks are worth knowing. A browser installed as a Flatpak shows the folder picker through the desktop portal, which works but may not offer locations outside your home directory. A browser installed as a Snap (Ubuntu's default Firefox) runs confined and can be refused access to some folders until you grant it in the Snap permissions; if a save fails silently, that is the first thing to check.

SSH quick reference

If the Linux machine will receive from other computers regularly, one-time setup pays for itself:

# on the Linux machine, once
sudo apt install openssh-server     # Debian/Ubuntu; dnf install openssh-server on Fedora
sudo ufw allow ssh

# from a Mac, Linux or Windows (PowerShell has OpenSSH built in)
scp ./video.mp4 user@linux-box:~/Videos/
rsync -avP --partial ./Photos/ user@linux-box:~/Photos/   # resumable, keeps structure

rsync is the one to learn: it copies only what changed, resumes a broken transfer from where it stopped, and preserves permissions and timestamps. Its cost is that the other end must have a terminal and your SSH login, which rules out phones for most people.

LocalSend and KDE Connect: the firewall lines

Both tools need incoming connections, and a Linux firewall that is on will block them silently: the device simply never appears on the other side.

sudo ufw allow 53317/tcp && sudo ufw allow 53317/udp      # LocalSend
sudo ufw allow 1714:1764/tcp && sudo ufw allow 1714:1764/udp  # KDE Connect

On Fedora and other firewalld systems the equivalent is firewall-cmd --add-service=kdeconnect --permanent; LocalSend needs the port added by hand. Flatpak versions of either tool work with the same rules; the firewall is on the host, not in the sandbox.

Where to get each tool

From a phone specifically

Phone to Linux is the case with the fewest good options, because the phone vendors' tools ignore Linux and SSH clients on phones are clumsy for picking photos. Three that work well: KDE Connect from an Android phone, which after pairing puts “send to laptop” in the Android share sheet; LocalSend on either phone platform, same network; and the browser link, which needs nothing installed on the phone and works from anywhere — the iOS app or Safari on an iPhone, the Android app or Chrome on Android, and Chromium on the Linux side for large files.

Frequently asked

Does it work in WSL?

WSL2 is a virtual machine with its own network. Receive with a browser on the Windows side, into a folder under \\wsl$\ or your Windows home, and Linux sees it; or run an SSH server inside WSL and scp to localhost. A browser launched inside WSL works too, but adds nothing.

The machine has no desktop

A headless server has no browser, so the browser link is out. scp or rsync over SSH is the answer, from any machine that has the file, including a phone via a terminal app, awkward as that is. For a one-off from a phone, send to a laptop with the browser link first, then rsync from the laptop.

Sending from Linux

The same page in Chromium or Firefox sends as well as receives, with folder picking in Chromium. LocalSend and KDE Connect send in both directions once installed. And for machines you administer, rsync outward is the same command with the arguments reversed.

Permissions on arrival

A file received through a browser is created with the browser's default permissions, typically readable and writable by you, readable by others, and not executable. Scripts and binaries therefore arrive without their executable bit and need chmod +x before they run; that is the browser being careful, not a transfer error. scp keeps the bits from the source; rsync -a keeps permissions, ownership where allowed, and timestamps. For anything that must stay executable, tar it first or use rsync.

Two methods you will see recommended that are not worth it

• python3 -m http.server. Starts a web server in the current folder so another device can download from it. It works, it is one command, and it is unencrypted, one-directional, and exposes the folder to everyone on the network. Fine on a trusted LAN in a pinch; not a habit.
• Bluetooth file transfer. Still present in most desktops and reliably slower than anything else on this page. A 100 MB file takes minutes.

Side by side

For a Linux user who wants one recommendation: install LocalSend for the devices you own, and keep the browser link for everyone else.