How it works

You drop a file and get a link

Your browser generates two random values: a 128-bit session id and a 256-bit encryption key. It builds a link like justdropfile.com/r/#session.key. The whole identity of the transfer sits after the # sign, called the fragment, and browsers never send the fragment to any server. At this point nothing has left your device except one WebSocket connection to our signaling service carrying the session id.

• •The QR code is the same link, drawn locally.
• •The link is valid for 20 minutes if nobody opens it, then the session is destroyed.

They open the link, and the browsers find each other

The receiving browser reads the fragment, connects to the signaling service with the same session id, and the two browsers exchange connection descriptors (SDP and ICE candidates) through it. That is the only job the server has: pass a few kilobytes of handshake between exactly two peers. It refuses a third, does not log the descriptors, and deletes the session the instant the peers connect.

A direct connection is tried first

WebRTC tries three routes in order: a direct local network path, a direct path across the internet using STUN to discover public addresses, and finally a relay. Most home and mobile networks allow one of the first two. The connection itself is encrypted with DTLS as WebRTC requires.

• •Direct connections have no size cap.
• •After connecting, the page checks which route was chosen and shows "direct" or "relayed".

If direct fails, an encrypted relay takes over

Some office, hospital, campus, and hotel networks block direct peer connections entirely. When that happens the traffic is relayed through Cloudflare TURN. The relay forwards ciphertext; it has no key. Relay credentials are minted per session by our worker and expire, so the relay cannot be borrowed as a free proxy. Relayed transfers are capped at 2 GB because relayed bytes cost money.

The receiver sees the file list and accepts

Before any file bytes move, the sender transmits an encrypted manifest: file names, sizes, and types. That goes over the peer connection, not through signaling, so our server never sees it. The receiver can decline. On accepting, the receiving browser opens a place to write the file: a folder you choose (Chrome and Edge on desktop) or the browser's private on-disk storage (Safari, Firefox, Android), so the file is written to disk as it arrives rather than held in memory.

Files stream across in encrypted pieces

The sender reads the file in slices of up to 64 KB, encrypts each slice with AES-GCM using the key from the link, and sends it over a WebRTC data channel. Each piece carries its file and position number as authenticated data, so a corrupted, missing, reordered, or replayed piece fails verification. At the end of each file the sender sends a signed count and byte total; the receiver confirms both before acknowledging. Files are sent one after another over one connection.

• •Neither side ever holds a whole file in memory. Multi-gigabyte transfers work on phones.
• •The sender respects the channel's backpressure, so a slow receiver slows the sender rather than filling its memory.
• •If the connection drops, the transfer fails clearly and the sender can make a new link. There is no resume in this version.