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
- Streamed to disk (Chrome/Edge desktop): you pick a location, chunks are written as they arrive, memory use stays flat. Files larger than your RAM are fine; multi-gigabyte transfers are limited by disk space and patience, not the browser.
- In-memory fallback (Firefox, Safari, mobile browsers): the file is held in memory until complete, then downloaded. This path is capped at 512 MB per file, and you are told before the transfer starts, because “it depends on your device” is not a promise anyone can keep.
Browser support
| Browser | Versions | Transfer | Streamed saving to disk |
|---|---|---|---|
| Chrome / Edge (desktop) | Current and previous stable | Supported | Yes: File System Access API, including folder saves |
| Firefox (desktop) | Current and previous stable | Supported | No: in-memory download, capped at 512 MB per file |
| Safari (macOS) | Current and previous major | Supported | No: in-memory download, capped at 512 MB per file |
| Chrome (Android) | Current stable | Supported | No: in-memory download, capped at 512 MB per file |
| Safari (iOS / iPadOS) | Current and previous major | Supported | No: in-memory download; background tab suspension applies |
| ShareDrop.org iOS / Android apps | Current release | Supported | Yes: written to storage as data arrives, no per-file cap |
Practical guidance
| Scenario | Recommendation |
|---|---|
| Multi-GB video or disk image | Receive on desktop Chrome or Edge, or in the mobile app (streamed saving) |
| Phone-to-phone photos | Fine everywhere; batches of moderate size are safest in iOS Safari |
| Whole folder | Chrome/Edge desktop preserves the folder structure; other browsers receive files individually with flattened names (details) |
| Sender on a laptop that might sleep | Keep 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
How Browser-to-Browser File Transfer Actually Works
A plain-language walkthrough of WebRTC data channels: how two browsers find each other, negotiate an encrypted link, and move file bytes without a server in the middle.
Direct P2P vs Encrypted Relay: What Is the Real Difference?
Speed, privacy and reliability trade-offs between a direct WebRTC connection and a TURN relay, and what the relay can and cannot see.
STUN, TURN and ICE, Explained Without Jargon
What actually happens when a WebRTC connection is being set up: the roles of STUN, TURN and ICE, and why a relay is sometimes unavoidable.
NAT Types Explained: Full Cone to Symmetric, in Plain Language
Why two devices behind home routers can usually connect directly and two devices behind carrier-grade NAT usually cannot: the four classic NAT behaviours, what STUN learns about each, and when only a relay will do.
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.