How ShareDrop.org works
ShareDrop.org moves files between two browsers over an end-to-end encrypted WebRTC connection. Here is the whole journey, with nothing glossed over.
1. You create a one-time room
Clicking Send files creates a room that lives for at most 10 minutes if nobody joins. Your browser generates a random secret locally and only sends a cryptographic commitment (a hash) of it to our server — the invite link keeps the actual secret in the URL fragment (the part after #), which browsers never send to servers.
You get three ways to invite the other device: a QR code, a link, and an 8-character short code you can read out loud.
2. The other device joins — and you approve it
The joining device proves it has the invite (the secret or the single-use short code). You then see an explicit “device requesting to connect” prompt. Nothing connects silently, and once two devices are linked the room refuses everyone else.
3. The browsers negotiate the best path
Both browsers exchange connection candidates through our signaling server (this is the only thing it relays — never file data) and try, in order of preference:
| Path | When | Shown as |
|---|---|---|
| Direct on your local network | Both devices on the same Wi-Fi/LAN | LAN direct |
| Direct across the internet | Routers/NATs cooperate (via STUN) | Internet direct |
| Encrypted relay (TURN) | Firewalls or strict NATs block direct paths | Encrypted relay |
The status badge reads the actually selected connection from WebRTC statistics. In relay mode the TURN server forwards packets that are already encrypted — it cannot read the file contents. See Direct vs relay: the real difference.
4. You can verify who is on the other end
Both devices independently compute a six-digit safety code from the DTLS certificate fingerprints of the encrypted connection. If both screens show the same code, no intermediary replaced the connection. Until you confirm it, the app honestly labels the session “identity not verified”. Details in How safety codes work.
5. Files move in verified chunks
The receiver first sees the file list — names, sizes, types — and chooses what to accept. Files then stream in 64 KiB chunks with flow control, so a file larger than your RAM cannot crash the tab. Both sides compute a SHA-256 checksum as bytes flow; a file is only marked done when both checksums match. If the connection drops, the transfer resumes from the last verified chunk once the link recovers.
6. The room disappears
When either side ends the session, the room state is deleted. There is no history, no account, and nothing to clean up. What our servers did and did not see is documented in plain language on the privacy page.