Sending large files between devices without the cloud: how peer-to-peer transfer works

The 4 GB video, the folder of RAW photos, the database dump: at some point every one of them meets the same wall. Email rejects it, chat apps re-encode it, and the cloud route means uploading the whole thing to a company’s servers so the other person can download it again — twice the transfer, plus a copy that lives somewhere you no longer control. There is a third path that most people never learn about, and it has been built into browsers for a decade: two browsers can connect directly to each other and stream a file between them, with no upload and no intermediate copy. This guide explains what actually happens on that connection, where it works and where it does not, and how to use the file sharing tool here — including the parts that fail and why.

Why the usual routes cap out

The email number surprises people: an attachment is encoded as text before it is sent, which adds roughly a third to its size, so a 20 MB file can exceed a 25 MB limit. And the cloud route’s real cost is not the storage — it is that a copy of the file now exists on a server, subject to that provider’s retention, scanning and breach history, long after both of you have finished with it.

What a direct transfer actually is

Browsers ship with WebRTC, the same technology behind video calls, and it includes a general-purpose encrypted data channel. Two browsers can open one and push bytes down it. The parts that matter:

• A signaling service introduces the two browsers. They need to exchange a small handshake — network candidates and encryption parameters — before they can talk directly, and that has to go via a server because neither knows where the other is. It handles the introduction only; once the two browsers are connected, it is out of the loop entirely and the file never touches it.
• The channel is encrypted end to end. WebRTC data channels are DTLS-encrypted as a mandatory part of the protocol — not an option someone can forget to enable.
• The file is streamed in small chunks— 64 KB at a time here, with flow control that pauses the sender when the receiver’s buffer gets full and resumes when it drains. That is what lets an arbitrarily large file move through a fixed amount of memory.

Sending, step by step

1. The sender picks files and gets a share link plus a QR code for it. The link is the whole handshake — anyone who opens it becomes the receiver, so treat it like a key.
2. Optionally, a PIN. Toggling it produces a random four-digit code you read out to the other person; they must type it before the transfer starts, and three wrong guesses lock the share permanently. The PIN check happens over the encrypted channel between the two browsers, so it never reaches any server. This is the control worth using when the link travels over a chat app you do not fully trust.
3. The receiver opens the link — on a phone, by scanning the QR code — and the two browsers negotiate a connection.
4. The receiver sees the file list and accepts, then chooses where to save. That choice has to be a deliberate click because the browser will only open a save dialog in response to a real user action.
5. The bytes move, with progress on both sides, and the page keeps the screen awake and warns before you navigate away mid-transfer.

The share is strictly two devices: a third person opening the same link is turned away with “this share link is already in use by two devices”. And the link is alive only while the sender’s page is open — close the tab and the link is dead, which is a feature rather than a limitation. Nothing outlives the session.

Direct, or relayed

Most home and mobile networks put devices behind NAT, so neither side has an address the other can dial. The standard fix is STUN: a lightweight server that tells each browser how it appears from the outside, after which the two can usually connect straight through. That is the normal case, and the one where nothing but the two devices ever touches the data.

Some networks — strict corporate firewalls, certain carrier-grade NAT setups on mobile data — refuse to be traversed. When that happens the connection can fall back to a relay: a server that forwards the encrypted stream between the two browsers. The tool tells you explicitly when a transfer is running that way, and the important property still holds — the relay forwards ciphertext it has no key for. It sees that two parties are exchanging data and how much; it cannot see what.

If a connection fails outright, the message says what to try, and the advice is worth repeating here: attempt it again, because routes vary between attempts, and if the two devices are in the same place, joining them to one Wi-Fi network is the surest fully-direct path — the bytes then never leave the building.

Saving a huge file without filling memory

The receiving side is where large transfers usually break, because the naive approach — assemble the whole file in memory, then trigger a download — falls over somewhere between one and two gigabytes. Where the browser allows it, this tool instead asks you to pick a destination up front and streams each chunk straight to disk as it arrives, so memory use stays flat regardless of file size. Sending several files at once, it can ask for a folder and write them individually.

That API is available in desktop Chrome, Edge and Opera. Everywhere else — Firefox, Safari, most mobile browsers — the transfer falls back to holding the file in memory and downloading it at the end, zipping multiple files together. It works, and it is the reason a very large transfer is better done to a desktop than to a phone.

When it does not work, and why

• Both pages must stay open. There is no store-and-forward. If the sender closes the tab, the link stops working immediately.
• Phones background aggressively. A phone that locks or switches apps mid-transfer may suspend the page. The tool holds a wake lock while transferring, but keeping the screen on is still the reliable move.
• Restrictive networks. Some corporate and captive networks block the traffic entirely. Same Wi-Fi, or a different network, is the fix.
• The link is single-use, for two devices. Sharing it in a group chat means the first two openers get the connection.

And the honest limitation: if the other person is asleep in another time zone, this is the wrong tool. A live transfer needs two live browsers. That is the trade you are making for not leaving a copy anywhere.

Make the file smaller first, when it makes sense

A transfer you do not have to make is faster than any protocol. Two cases are worth a minute before sending:

• Video. Phone footage is often several times larger than it needs to be for anything but archival use. The video compressor can take a multi-gigabyte clip down to a fraction of its size in the browser — the video compression guide covers the settings that matter.
• Many small files. Hundreds of files transfer more smoothly as one archive. If what you have received is an archive, the extractor here opens ZIP, RAR, 7Z and TAR in the browser without installing anything.

How the options compare on privacy