Practical engineering guide

DropItOver versus Snapdrop: browser transport and stored-link tradeoffs

Reviewed against the implementation: October 17, 2026

DropItOver and Snapdrop both offer a browser-oriented file-sharing experience, but a useful comparison must separate discovery, transport, storage, and delivery timing. Two sites can use WebRTC and still behave differently because of their signaling deployment, relay configuration, file assembly, and UI. This page compares the documented Snapdrop project with the implementation in this repository, rather than claiming to have measured every hosted instance. It explains where the approaches overlap, where DropItOver adds a different stored-link workflow, and how to test either option on your actual network without publishing invented speed or memory rankings.

Identify the exact deployment

Snapdrop's published project describes browser sharing using WebRTC and WebSockets. Hosted instances and forks can change configuration, availability, and features, so record the address and version when possible. Do not assume that a restriction observed on one instance applies to every related project. PairDrop, for example, documents its own pairing and deployment features and should not be treated as a synonym for every Snapdrop installation. Consult each project's primary documentation when a particular feature determines your choice.

DropItOver's nearby service groups browsers using a hash of the public IP seen by its Worker. It does not scan a private subnet. Room invitations provide an explicit shared identifier across discovery groups. Live payloads use SCTP over DTLS, while stored links use an HTTPS Worker, D1 metadata, and R2 file objects. That separation is visible in the code and matters when a transfer fails. A device appearing in a list establishes signaling, not successful data routing or verified recipient identity.

Diagnose the common browser constraints

When neither page shows a peer, inspect connectivity to the signaling service and whether the devices meet the instance's grouping rules. A VPN can change internet egress and browser privacy tools can affect connections. With DropItOver, an explicit room removes reliance on the nearby list but still needs a usable ICE route. On public or guest Wi-Fi, client isolation may allow both sites to load while blocking a direct connection. Switching sites alone does not change the router's forwarding policy.

On Windows 11, check the active network profile and browser application rule without disabling the firewall. On a router you control, try the trusted main SSID or a personal hotspot before editing isolation settings. On managed equipment, request an approved route from the administrator. A configured, reachable TURN relay can carry encrypted WebRTC traffic when a direct path fails, but that capability varies by deployment. Do not claim every Snapdrop-like site is direct-only or that every DropItOver session can bypass restrictive networks.

Browser live path: signaling introduces peers -> ICE selects route -> DTLS/SCTP
Possible relay path: sender ===== TURN encrypted packet relay ===== receiver
DropItOver stored path: sender -> Worker/R2 -> recipient after upload completes

Keep execution and saving in the comparison

Both the sender and receiver need working browser execution for live transfer. iOS Safari can suspend pages after app switching or screen lock; Android power policy also varies. Keep pages visible and the screen awake while testing. A page installed as a shortcut is not automatically a background transfer service. If one test ran foregrounded and another ran while the phone locked, the timing difference does not isolate the transport. Record interruption conditions and distinguish an active transfer failure from an empty discovery list.

DropItOver bounds the sender's queued data using bufferedAmount and groups received buffers into Blob parts. The final Blob still represents the whole file. Resource usage can therefore grow with the received file even though individual messages are small. Do not compare a source-code chunk constant with another product's measured process memory. Test actual peak usage with the same device and observation method, and document whether browser-managed disk backing is included. A large video can fail on one receiver and succeed on another without any signaling defect.

Stored links change the trust and timing model

When a recipient cannot stay online, DropItOver's link mode uploads a completed share for later retrieval. The Worker processes plaintext, derives file keys from its master secret, encrypts chunks with AES-256-GCM for R2, and decrypts downloads. Metadata and notes are in D1. This is server-managed encryption at rest, not zero-knowledge storage. Do not describe the live and stored modes as having the same operator-access boundary. If an offline recipient is not required, live delivery may avoid unnecessary server file retention.

Defaults cap link files at two GiB and bundles at eight GiB, with daily anonymous quotas. Choose an expiry that covers the recipient's arrival and possible retries. Burn-after-read and early deletion remove the managed share, not copies a recipient saved or forwarded. Download range resumption is not implemented for the encrypted stream. Keep the source until the recipient verifies a usable copy. A feature comparison should list these constraints instead of calling the mode unlimited simply because it has no subscription form.

Test bytes before testing speed

Use one harmless file of known size on the same two devices. Confirm discovery, acceptance, data-channel opening, payload completion, and final saving in order. Compare the saved size and, for important artifacts, a SHA-256 digest. A progress bar reaching the end does not establish that the selected source was the intended document or that a hidden browser prompt was completed. Run the small fixture first, then a representative larger file, so memory limits do not obscure basic routing problems.

Record device models, OS and browser versions, network layout, VPN state, relay status, source bytes, and timing boundaries. Repeat each configuration three times and report medians. Keep setup and saving separate from payload time. If a hosted site is unavailable during testing, report that availability observation with its time; do not convert one outage into a permanent protocol claim. A self-hosted instance with different relay settings can legitimately produce different results.

These are calculations, not measured Snapdrop or DropItOver benchmarks. LocalSend uses a local application protocol and requires its own controlled test; it cannot be assigned a speed from this table. Use the workflow that meets your installation, availability, privacy, and reliability needs. Keep a record of a successful configuration and recheck after meaningful software or network changes. Support reports should describe the failed stage and safe environment details while keeping private documents, device addresses, credentials, room invitations, and active download links out of public logs.

Sources and further reading

Snapdrop source, PairDrop documentation, LocalSend protocol. Implementation details above describe this repository; calculated tables are not measured hardware results.