Peer-to-Peer File Transfer

Two browsers, one drop zone

This page moves files directly between exactly two browsers, and nothing else ever holds them. You get an eight-character ID the moment you start. The other person types it in, opens your invite link or scans the QR code, and the drop zone unlocks once the connection stands. The IDs, the invite link and the way two browsers find each other through public Nostr relays and Cloudflare's STUN server are the same as on the peer-to-peer chat, and that page walks through every step of the setup, including what the relays and the STUN server get to see.

Sending is dropping. Every file you drop is announced to the other side with its name, size and type, and nothing beyond those three values leaves your machine until the other person clicks save. They can decline instead, and either side can cancel a running transfer at any point. Each file gets its own row with progress, current speed and time left, and its own encrypted data channel on the connection the two tabs already share, so several files run at once without taking turns.

The six-digit safety code above the drop zone hashes the certificate fingerprints of both ends, the same check the chat and the video call use. Read it to each other over the phone once and a relay in the middle is ruled out.

As in every peer-to-peer connection, the other person sees your IP address.

Why upload services cap out and this page does not

An upload service has to store your file, and storage is what its limits protect. Every transfer sits on a disk in a data center until the link expires, so the free tier gets a cap and a countdown. WeTransfer's free plan currently allows 10 transfers or 3 GB in total per rolling 30-day window, and Wormhole stores at most 5 GB per file, deleted after 24 hours.

Here there is nothing to protect, because there is no storage. The sender reads the file from disk in 64 KB slices, pushes each slice into the encrypted data channel, and the receiving browser writes it out on the far side. No copy accumulates anywhere in between, which is why the sending side has no size limit at all. A 20 GB file passes through the same few megabytes of memory as a 2 MB one.

const buf = await file.arrayBuffer();
channel.send(buf);

const slice = file.slice(sent, sent + 65536);
channel.send(await slice.arrayBuffer());

The price of having no server is that there is no store and forward. Both tabs stay open until the last byte is through, and if the two networks cannot reach each other directly, mobile carriers and office firewalls are the usual suspects, the transfer does not start at all. This page deliberately runs without a TURN relay, and the chat article explains when a direct connection fails.

Where an incoming file lands

The interesting limit sits on the receiving side, and it depends entirely on the browser. Chrome and Edge on the desktop, and Chrome on Android since version 132, have the File System Access API. The save dialog hands the page a writable stream, and every chunk goes to disk the moment it arrives, so a file of any size passes through a few megabytes of memory and nothing more. Choose a folder once and every incoming file lands there without another dialog, with name collisions numbered the way downloads are, photo (2).jpg.

Firefox and Safari have no save picker, so an incoming file grows in memory until it is complete and becomes a regular download at the end. Up to roughly 1 GB that works fine. Beyond it, receive in Chrome or Edge, and on iPhones and iPads, where every browser runs on Safari's engine, plan for a few hundred MB rather than gigabytes. The page checks which case applies and says so before the first file is offered.

In both modes nothing touches the disk before you click save, and a cancelled or broken transfer deletes the partial file instead of leaving half a download behind.

What sets the speed

A data channel message may carry 64 KB in any browser without asking what the other side negotiated, the safe figure under the message size rules of RFC 8831. So 64 KB is the chunk size here. The sender keeps up to 4 MB of chunks queued in the channel and reads the next slice from disk once the queue drains below 1 MB. That backpressure is visible on the page, the send queue chart saws between the two marks for as long as a transfer runs.

Between two tabs on one machine this moves 26 MB/s, about 420 chunks per second, and a 150 MB test file arrived with a SHA-256 identical to the source. Across a real network the slower of your upload and their download sets the pace, and on home connections that is almost always the sender's upload. The page prints no estimate for that case, because we have not measured one.

DTLS already authenticates every packet on the wire, so the page does not hash the finished file. We accept that a write error on the receiving side would go unnoticed, and checked the pipeline once with that SHA-256 comparison instead of making every transfer pay for a hash over gigabytes.

The round-trip chart tells you something during a transfer too. The ping travels over the same connection as the chunks and queues behind them, so a round trip that climbs while a transfer is fast means the link is running at capacity, not that something is wrong.

When a transfer breaks

A cancelled file says which side cancelled, a closed tab reads as connection was closed. There is no resume, an interrupted file starts over from zero. The page warns before you close a tab mid-transfer, and folders are skipped at the drop zone.

To send a folder, zip it first.

WeTransfer, Wormhole, AirDrop or scp

For a recipient who is asleep in another timezone, an upload service wins, because store and forward is the one thing a serverless transfer cannot do. AirDrop wins between two Apple devices in the same room. scp wins when you have shell access on one end and both machines are yours anyway.

The browser transfer wins one case clearly. Two people online right now, a file bigger than the free caps, and nobody willing to create an account or install anything. Wormhole above 5 GB is the same mechanism, a browser to browser stream with the tab kept open, with server storage as the fallback below.

It is the wrong tool when the other person cannot stay online until the end, and when both sides sit behind carrier-grade NAT, because there is no relay to fall back on.

Size caps, slow transfers and where the file actually lands