Send Files Between Two Computers: Windows, Mac and Linux, Near or Far

By ShareDrop.org Engineering · Published Sep 20, 2026 · Updated Oct 17, 2026

Two computers, one file, no USB stick. The right method depends on two things: how far apart the machines are, and whether they run the same system. Windows, macOS and Linux each have a good tool for the same desk, the office network has an old and very fast one, and the internet case (a relative's PC in another city, your own desktop at home) needs a different approach altogether. Pick by distance and you will rarely be disappointed; pick by habit and you will be uploading to the cloud to move a file across a desk.

Pick by distance

Same desk: the built-in tools

Windows to Windows: Nearby Share. Windows 10 (version 1803 and later) and Windows 11 include it. Turn it on in Settings → System → Nearby sharing on both PCs, set it to Everyone nearby temporarily, right-click a file → Share → pick the other PC. It finds the other machine over Bluetooth and moves the data over Wi-Fi, at original quality, with nothing to install. It sends files, not folders, so zip a folder first. Google's Quick Share for Windows does the same job with the same limits, and adds Android phones.

Mac to Mac: AirDrop. Same idea, same requirements: Bluetooth and Wi-Fi on, both Macs awake, receiving set to Everyone for 10 Minutes if they are not signed into the same Apple ID. The failure modes are the ones an iPhone hits (AirDrop symptom by symptom).

Any mix, including Linux: LocalSend. Open source, free, packaged for Windows, macOS and every major Linux distribution (Flatpak, AppImage, Snap, AUR, .deb and .rpm), with phone apps too. Devices on the same Wi-Fi discover each other and transfer directly, original files, no account. Like every local tool, it needs installing on both sides and cannot cross networks.

When Nearby Share does not find the other PC

• Both PCs need Bluetooth and Wi-Fi on. A desktop with no Bluetooth adapter cannot use it; a USB Bluetooth dongle fixes that.
• My devices only requires the same Microsoft account on both; use Everyone nearby while sending.
• Discovery is Bluetooth range: bring them within a few metres.
• If the transfer starts but crawls, the PCs are not on the same Wi-Fi network and have fallen back to Bluetooth.

Same building: a network share

The oldest method is still the fastest for large amounts of data on a wired or Wi-Fi 6 network. Copies run at the full speed of the link (a gigabit cable moves 100 MB/s sustained), and folders keep their structure. Setting one up on Windows 11:

1. On both PCs: Settings → Network & internet → your connection → Properties → set the network profile to Private. A share on a Public-profile network is blocked by the firewall no matter what else you do.
2. Settings → Network & internet → Advanced network settings → Advanced sharing settings → under Private, turn on Network discovery and File and printer sharing.
3. On the source PC, right-click the folder → Properties → Sharing → Advanced Sharing → tick Share this folder → Permissions → give your account Read (or Change). On the Security tab, make sure the same account has access; both tabs must allow it.
4. On the other computer, connect by name. Windows: type \\SOURCE-PC in File Explorer's address bar. Mac: Finder → Go → Connect to Server → smb://SOURCE-PC. Linux: the file manager's “Other Locations” or address bar, smb://SOURCE-PC. Sign in with an account that exists on the source PC; for a Microsoft account, that is the full email address and the account password, not the PIN.

If the source PC does not appear under Network, connect by name anyway: discovery is flaky, direct addressing is not. “Windows cannot access” almost always means the Security tab (step 3) or the firewall rule File and Printer Sharing (SMB-In) being off for the Private profile. On a guest or hotel network, client isolation blocks shares entirely (why).

For a large folder tree, File Explorer's drag-and-drop stops at the first error. The built-in robocopy is what the job needs:

robocopy C:\Projects \\SOURCE-PC\Share\Projects /E /Z /R:2 /W:5 /MT:8

/E copies subfolders including empty ones, /Z makes each file resumable if the connection drops, /R and /W limit retries so a locked file does not stall the run, and /MT:8 copies eight files at once, which matters enormously for thousands of small files. Run it again after an interruption and it skips what already arrived.

Macs, Linux and anything with SSH

Between Macs and Linux machines, or from Windows with its built-in OpenSSH client, scp and rsync move anything, resume interrupted copies and keep permissions and structure. One-time setup on the receiving Linux machine:

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 where it stopped, and preserves permissions and timestamps. On a Mac, turn on Remote Login in System Settings → General → Sharing to receive the same way. The cost is that the other end needs a terminal and your login, which makes it the right tool for admins and the wrong one to explain to a relative.

LocalSend and KDE Connect need incoming connections, and a Linux firewall that is on blocks them silently: the device simply never appears.

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 its port added by hand. Flatpak versions use the same rules, because the firewall is on the host.

Different networks: why it is the hard case

On one network, computers have addresses that reach each other and can find each other by broadcasting. Across the internet, neither is true. Each sits behind a router doing network address translation, so it has no public address of its own and cannot be reached unless it opened the door first (how NAT works), and there is no broadcast to find anyone. Every cross-network method solves this in one of three ways:

• Route everything through a server: cloud sync, upload links, email. The server is reachable, so both sides talk to it instead of to each other.
• Introduce the devices, then step aside: peer-to-peer with NAT traversal. A server helps them find each other; the data goes direct.
• Build a private network across the internet: a VPN or mesh network. Powerful, and more setup than a single transfer deserves.

The peer-to-peer route takes about a second:

1. Both computers open a page and are matched by a short code. The rendezvous server learns that two devices want to connect, not what they will send.
2. Each asks a STUN server what its public address looks like from outside (STUN explained).
3. They exchange those addresses and send packets to each other at the same time. On most home routers that opens both firewalls, “hole punching,” and the connection is direct.
4. If the routers refuse (symmetric NAT, a corporate firewall, a mobile carrier), they fall back to a relay that forwards their encrypted packets and cannot read them (what the relay can see).

The direct browser link, step by step

1. On the receiving computer, open sharedrop.org in Edge, Chrome or Chromium and click Create transfer.
2. On the sending computer, open the same address and type the six-character code into Join (or share the invite link instead of the code).
3. The receiving side sees a “wants to connect” prompt; accept it. Compare the six-digit safety code once, over the call or chat you are already on.
4. Pick files or a whole folder on the sending side; the receiver accepts the list, and each file is checksum-verified on arrival.

The status badge tells you which path won: Internet direct means hole punching worked, Encrypted relay means the fallback was needed. In Chrome, Edge and other Chromium browsers the receiving computer writes to disk as data arrives and keeps folder structure (details). Nothing is installed on either side and no copy is kept anywhere.

This is also the method for a computer you cannot walk over to. A parent's PC in another city needs exactly one action from them: open a web address, click Create transfer, and read you the code over the phone. You send; they accept the file list; the safety code is read aloud once.

A worked example, with the numbers

A laptop tethered to a phone's 5G hotspot in one city sends a 1.2 GB video to a desktop on home broadband in another. The carrier uses symmetric NAT and the home router is a port-restricted cone, so hole punching between them fails (why that pair cannot punch through), and about two seconds after the code is entered the badge settles on Encrypted relay. The 5G upload measures 40 Mbps, so the transfer runs at about 5 MB/s and finishes in four minutes. The relay adds around 40 ms of latency and changes the throughput not at all. With IPv6 on both sides the badge would have read Internet direct, and the four minutes would have been the same four minutes, because the sender's upload is the ceiling either way (diagnosing slow transfers).

Making a remote transfer go smoothly

• Treat it like a call. A direct transfer needs both computers online at once. Close a laptop lid and the transfer pauses; it resumes from the last verified chunk when the lid opens. For a multi-hour transfer over a slow upload, plug both in and set them not to sleep.
• Make the code when the other person is ready. A short code is valid for minutes, not hours. It is single-use, so it is safe to say aloud or type into a chat.
• Both prompts need a tap. The connect prompt and the file-list prompt waiting on an unwatched screen look exactly like a connection that will not come up.
• Your own two computers, weekly? A mesh VPN (Tailscale or similar) gives each a private address the other can always reach, and the badge then reads LAN direct across the internet (how VPNs affect transfers).
• On an office network that blocks it, the request to IT is small: outbound UDP to port 3478, or at least outbound TCP to 3478 and 443. Nothing inbound and no port forwarding; it is the same traffic video calls use.

Receiving in each browser

Chrome, Edge, Brave and Chromium on Windows, macOS and Linux support the File System Access API: the transfer asks once for a destination folder and writes every file, and subfolders, straight to disk. Firefox and Safari do not; they hand each file to the download manager, assembling it in memory first, which is where the 512 MB per-file cap comes from (why). On Linux, two packaging quirks matter. A Flatpak browser shows the folder picker through the desktop portal, which may not offer locations outside your home directory, and a Snap browser (Ubuntu's default Firefox) can be refused access to some folders until you grant it; if a save fails silently, check that first. A file received in any browser arrives without its executable bit, so scripts need chmod +x; for anything that must stay executable, tar it or use rsync -a.

Speed, for the same 10 GB

On a wired LAN nothing beats a share or rsync. On the same Wi-Fi the methods sit within a factor of two of each other, and across the internet they all wait behind the same upload line.

Side by side

When the cloud is the right answer

A direct transfer needs both computers online at once; cloud sync does not, and for files that should live on both machines permanently it is the right tool. With OneDrive's Files On-Demand, a file that appears on the second PC may be a placeholder that downloads when opened; right-click → Always keep on this device for anything you need offline. A large drop is not on the other machine until it has gone up and come down, and a file deleted on either computer is deleted on both: the folder is one thing in two places, which is the feature and the hazard. For a one-off file to someone who is asleep in another time zone, a link with an expiry is the honest choice (the trade-offs).

Two methods that are not worth it

• python3 -m http.server. One command, and another computer can download from the folder. It is also 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. Present on most computers and slower than anything else here: a 100 MB file takes minutes.

Frequently asked

Does any of this work in WSL?

WSL2 is a virtual machine with its own network. Receive with a browser on the Windows side into a folder Linux can see, or run an SSH server inside WSL and scp to localhost.

The receiving machine has no desktop

A headless server has no browser, so scp or rsync over SSH is the answer, from any machine that has the file.

It will not connect at all

Rarely, a network blocks both the direct path and the relay: a corporate firewall that allows only approved web traffic, or a VPN that captures everything (VPN effects). Move one computer to a phone hotspot, which gives it an ordinary consumer connection; if the network is locked down on purpose, use what the organisation sanctions. For a phone on one end instead of a computer, see phone to computer.