Can I send a 10 GB file without uploading it anywhere?

Yes, with a browser-to-browser transfer. WebRTC datachannels move the file in blocks from the sender's machine to the recipient's, so nothing is stored on an intermediate server. The trade-off is that the sender has to stay online and keep the page open for the whole transfer.

Why is a cloud-drive link different?

A cloud-drive or WeTransfer-style link is a two-step transfer: the file is uploaded to the provider's storage first, then downloaded from it. That is convenient when the sender and recipient are not online at the same time, but it means a third party holds the file, and you pay their storage and egress limits.

Is peer-to-peer transfer encrypted?

WebRTC encrypts the transport by default (DTLS-SRTP), which protects against the network but not against the relay. For file delivery you want content-level end-to-end encryption on top, where the key never reaches any server. StraightPath puts the key in the URL fragment, which browsers never transmit.

Why is my peer-to-peer transfer slow?

Usually one of three things: the sender's upload bandwidth (the real ceiling, and asymmetric on consumer connections), the transfer being relayed through TURN because both peers are behind symmetric NAT, or a mobile browser throttling a backgrounded tab.

Does the recipient need to install anything?

No. A modern browser is enough, on desktop or phone. If the link is delivered as a QR code, scanning it with the phone's camera app opens the browser directly.

What happens if the connection drops mid-transfer?

It depends on whether the client writes received blocks to disk. If it does, the transfer is resumable: reopening the link fills only the missing blocks. If it keeps everything in memory, you start over.

← StraightPath

Sending large files without a server: what actually works

Moving a 20 MB document is solved. Moving 20 GB — a dataset, a video project, a raw disk image, a folder with 600 files in it — is where most "file sharing" options quietly stop working. This is an honest map of the four ways to do it from a browser in 2026, what each one costs, and where browser peer-to-peer genuinely loses.

The short version

If both parties can be online at the same time and neither wants the file stored on a third-party server, transfer it browser-to-browser over WebRTC: no upload, no download-again-from-the-cloud, no quota, no expiry date on the link. If the recipient will show up hours or days later, you need storage, and a server is the right tool — just know that is what you are paying for.

The four options, compared

Method	Where the bytes live	Practical ceiling	What it costs you
Email attachment	Both mailboxes, plus every relay in between	25 MB, sometimes 10 MB	Nothing else — that is why the ceiling is so low
Cloud drive / transfer service link	The provider's servers, until the link expires	2–200 GB depending on plan	Account, upload time, provider egress cap, and a third party holding the file
Object storage with a presigned URL	Your own bucket	Effectively unlimited	You run a backend, you pay egress per download, you manage credentials
Browser peer-to-peer (WebRTC)	Nowhere in between	Sender's disk and the recipient's disk	Both sides must be online for the whole transfer; sender's upload bandwidth is the ceiling

Why the browser can do this at all now

Five APIs landed and made the fourth option real rather than a demo:

WebRTC datachannels — ordered or unreliable binary channels between two browsers, with SCTP handling fragmentation. This is the pipe; it is the same transport video calls use.
OPFS (Origin Private File System) — a sandboxed filesystem in the browser with real sequential write throughput. Blocks land on disk as they arrive instead of accumulating in memory, which is what makes a 40 GB transfer possible at all.
WebAssembly — fast hash and cipher implementations without a native build. ChaCha20-Poly1305 for the browsers where WebCrypto is unavailable.
WebGPU — the BLAKE3 Merkle tree that proves the file arrived intact can be folded on the GPU instead of the CPU. On a machine without a GPU it degrades to wasm, then to plain TypeScript, and the verification still happens.
Workers — so none of the above blocks the thread painting your progress bar.

"Serverless" still needs somewhere to exchange phone numbers

Two browsers on the public internet cannot find each other from nothing: something has to carry the session description and the ICE candidates. That is signalling, and it is the only part of the flow that touches a third party. The options are a WebSocket relay you run yourself, or a public one. StraightPath uses public Nostr relays — a message-propagation network designed for exactly this shape of small, ephemeral, unauthenticated-but-keyed traffic — plus public STUN resolvers and opt-in TURN relay.

Crucially, signalling carries no file bytes. And the encryption key is not in it either: the key lives in the URL fragment (#k=…), and browsers never transmit fragments to servers, never put them in Referer, and (in this app) never write them into the address bar or history. Whatever observes the signalling sees a room id and ciphertext.

Where peer-to-peer is worse, stated plainly

Both sides must be online. The sender's tab is the server. Close it and the offer is dead. If you need "drop a link and go to bed", use storage.
The sender's upload bandwidth is the ceiling. Consumer fibre is often asymmetric — a 500 Mbps download line with 30 Mbps upload tops out around 3.7 MB/s no matter how fast the recipient's machine is.
Corporate networks can force a relay. Two peers behind symmetric NAT fall back to TURN, which is a server in the middle again (for the bytes, not for storage) and slower. It is opt-in because it depends on a public relay being up.
Mobile browsers throttle background tabs. Send from a laptop, or keep the phone's screen on the page.
One sender, N recipients costs N transfers. A CDN fans out for you because the bytes sit on a server. Peer-to-peer does not; each recipient pulls from the sender separately.

Step by step: a 10 GB folder, browser to browser

The sender opens the page and drops the folder. Nothing is uploaded — the browser reads the files locally and starts hashing them into a Merkle tree, block by block.
The page produces a link and a QR code. The link is the whole delivery: room id plus key.
The recipient opens it. Their browser decrypts the manifest with the key — file names, sizes and the expected root are all sealed, so an observer learns nothing — and starts requesting blocks.
Blocks stream in, are decrypted, and are written to OPFS immediately. Memory stays flat; disk usage grows by exactly the amount received.
At the last byte the recipient recomputes the entire Merkle root locally and compares it with the sealed one. Verification is a full re-read, deliberately not trusting the receive path that produced the bytes.
The recipient exports to a real folder. If they close the page halfway, reopening it asks whether to fill the remaining blocks or delete what arrived and start over.

Troubleshooting

The recipient sees nothing happening.: Nine times out of ten the sender closed the tab. The offer only lives as long as the page that made it.
It connects but crawls.: Check the sender's upload speed first — that is the ceiling. If both ends are on office or carrier NAT, enable TURN under Advanced settings and accept the slowdown in exchange for a working path.
Verification failed.: The client refetches the affected blocks a bounded number of times and then stops and says so, rather than looping forever. A genuine failure means either the sender's file changed mid-transfer (re-share it) or something corrupted blocks in flight — the Merkle root exists precisely so this cannot pass silently.
It is eating my disk.: Received blocks are real bytes on your disk until you export and clean up. A good client shows you the number and gives you a button that gives the space back.
Can I paste the link into a group chat?: Yes, but treat it as a secret: the link contains the key. Anyone who opens it while the sender is online can receive the file. Short-lived offers and a private channel are the mitigation.

Which one should you use

Under ~25 MB and one recipient: email, honestly. Recipient appears later, or you need a permanent link: a cloud drive, and pay the storage. You are building infrastructure and want programmatic control: object storage with presigned URLs. Both parties online, file is large, and you would rather the bytes went directly: browser peer-to-peer — which is what StraightPath is for.