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 a six-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:

LAN direct FASTEST

Same Wi-Fi: peer to peer, never leaves your network.

Internet direct DIRECT

Across networks, peer to peer via STUN hole punching.

Encrypted relay FALLBACK

Firewalled networks: the relay forwards ciphertext it cannot read.

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.

Limits & compatibility

There is no artificial size limit in the ShareDrop.org protocol, and WebRTC itself works in every modern browser. The real limits come from how each browser lets a page write received data to disk, and that changes what can be promised per platform.

The two saving paths

Browser support

BrowserVersionsTransferStreamed saving to disk
Chrome / Edge (desktop)Current and previous stableSupportedYes: File System Access API, including folder saves
Firefox (desktop)Current and previous stableSupportedNo: in-memory download, capped at 512 MB per file
Safari (macOS)Current and previous majorSupportedNo: in-memory download, capped at 512 MB per file
Chrome (Android)Current stableSupportedNo: in-memory download, capped at 512 MB per file
Safari (iOS / iPadOS)Current and previous majorSupportedNo: in-memory download; background tab suspension applies
ShareDrop.org iOS / Android appsCurrent releaseSupportedYes: written to storage as data arrives, no per-file cap

Practical guidance

ScenarioRecommendation
Multi-GB video or disk imageReceive on desktop Chrome or Edge, or in the mobile app (streamed saving)
Phone-to-phone photosFine everywhere; batches of moderate size are safest in iOS Safari
Whole folderChrome/Edge desktop preserves the folder structure; other browsers receive files individually with flattened names (details)
Sender on a laptop that might sleepKeep the tab in the foreground; transfers resume after brief drops, but a sleeping machine sends nothing

Why the same is not promised everywhere

Some tools claim “unlimited file size on all devices”. In a browser, that is not truthful: streamed saving is simply not available on every engine. The approach here is capability detection: the app checks what your browser can actually do and sets expectations before a single byte moves. Background on the engineering is in why large files crash browser tabs.

Verification status

The automated end-to-end suite exercises the full transfer flow (room creation, join, accept, transfer, hash verification) on Chromium and WebKit engines, plus the room and invite flows on Firefox; the WebRTC leg on Firefox and physical-device testing on iOS and Android are verified manually and tracked in the release checklist. This page is updated as claims are verified. Under-promising here is preferable to listing a matrix that has not been run.

Go deeper

Common questions

Is ShareDrop.org free?

Yes. The transfer product is free to use, with no account and no file size pricing tiers.

Do I need to create an account?

No. There are no accounts anywhere in the product. Each transfer is a one-time session between two devices.

Is ShareDrop.org related to ShareDrop or Snapdrop?

No. ShareDrop.org is an independent project, not affiliated with the earlier open-source ShareDrop or Snapdrop projects, and shares no code or infrastructure with them.

Start a transferFree, no account, nothing to install.