HOW IT WORKS

Direct, not uploaded.

A plain-language explanation of the current web version

1. Choose one or more files

The files stay on the sender’s device. DirectDrop reads them in small chunks only after a recipient connects and starts receiving. Selecting multiple files creates one streaming ZIP64 download without first building a second full copy in memory.

2. Create a private link

The server creates a random room and short-lived, role-specific admission tickets. The browser adds a separate cryptographic secret to the URL fragment—the part after #. Browsers do not include that fragment in normal HTTP requests.

3. Establish the peer connection

The signaling server briefly forwards WebRTC offers, answers, and network candidates so both browsers can find each other. Those messages are authenticated using the link secret. Google’s public STUN service helps each browser discover a direct network path.

4. Transfer through WebRTC

File names, sizes, hashes, and file bytes travel through the encrypted WebRTC data channel between the two peers. The DirectDrop application server does not receive or store the files. Each file is hashed independently with SHA-256 so the receiver can verify it arrived intact.

5. Save as a stream

Supported desktop browsers can write directly to a user-selected destination. Other supported browsers use the Downloads system through a service worker. DirectDrop keeps only a bounded amount of data in memory while transferring, so the file can be much larger than the available RAM.

What the server still does

Important limitations

Both browser pages must remain open and active. Mobile operating systems may suspend background browsers. A live page can reconnect after a network or peer-connection break, and supported desktop browsers can reload-resume a single direct-file download from a durable checkpoint. ZIP and normal browser-download streams still restart after reload. The production service currently has no TURN relay, so some restrictive networks may be unable to connect.