Quick Verdict
PairDrop and Send solve different problems. PairDrop is for instant, local file transfers between nearby devices — think AirDrop. Send is for sharing files with anyone via encrypted, expiring links — think WeTransfer. Pick based on your use case, not which is "better."
Overview
PairDrop is a peer-to-peer file sharing tool inspired by Apple's AirDrop. Devices on the same network discover each other automatically, and files transfer directly between browsers via WebRTC — nothing touches the server. No accounts, no links, no storage.
Send is a fork of the discontinued Firefox Send. Upload a file, get an encrypted link with a download limit and expiry time. Files are end-to-end encrypted in the browser before upload. Share the link with anyone — they don't need to be on your network.
Feature Comparison
| Feature | PairDrop | Send |
|---|---|---|
| Transfer method | Peer-to-peer (WebRTC) | Upload → link → download |
| Discovery | Auto-discover on LAN | Manual link sharing |
| Encryption | WebRTC (DTLS) | End-to-end (browser-side AES-GCM) |
| File size limit | None (peer-to-peer) | Configurable (default ~2.5 GB) |
| Expiring links | N/A | Yes (time + download count) |
| Password protection | N/A | Yes |
| Server storage needed | None | Yes (stores encrypted files) |
| Account required | No | No |
| Text/message sharing | Yes | No |
| Multiple recipients | Yes (all LAN devices) | Yes (anyone with the link) |
| Offline transfer | No (needs server for signaling) | No (needs server for storage) |
| Mobile support | Browser-based (all platforms) | Browser-based (all platforms) |
| External sharing | With TURN server only | Yes (anyone with the URL) |
| License | GPL-3.0 | MPL-2.0 |
Installation Complexity
PairDrop is about as simple as self-hosting gets. One container, no database, no persistent storage. Files never touch the server — it only handles WebRTC signaling.
# PairDrop — that's the entire stack
services:
pairdrop:
image: ghcr.io/schlagmichdoch/pairdrop:v1.11.2
ports:
- "3000:3000"
restart: unless-stopped
Send requires two containers (app + Redis) and persistent volume storage for uploaded files. Configuration involves setting BASE_URL, upload limits, and expiry defaults.
# Send — needs Redis + storage volume
services:
send:
image: registry.gitlab.com/timvisee/send:v3.4.27
ports:
- "1443:1443"
volumes:
- ./uploads:/uploads
environment:
- REDIS_HOST=redis
depends_on:
- redis
redis:
image: redis:7-alpine
Winner: PairDrop — single container, zero configuration, zero storage.
Performance and Resource Usage
PairDrop's server component is a lightweight Node.js signaling server. Since files transfer directly between browsers, the server handles almost no data. RAM usage is negligible (~30 MB).
Send stores files on the server (encrypted), so disk usage scales with transfer volume. The Node.js app itself is lightweight (~50-80 MB RAM), but Redis adds another ~30 MB, and you need disk space proportional to your upload limits.
| Metric | PairDrop | Send |
|---|---|---|
| RAM (idle) | ~30 MB | ~80-110 MB (app + Redis) |
| Disk usage | None | Proportional to uploads |
| Network load on server | Signaling only (~KB) | Full file upload + download |
| Containers | 1 | 2 (app + Redis) |
| Bandwidth impact | Direct between peers | Server acts as intermediary |
Winner: PairDrop — minimal resource usage since files bypass the server entirely.
Community and Support
PairDrop has ~4,500 GitHub stars and active development. It's a fork of Snapdrop with significant improvements (rooms, persistent pairing, text sharing). Documentation covers Docker deployment and TURN server setup.
Send has ~4,800 GitHub stars. It's a maintained fork of Firefox Send (discontinued by Mozilla in 2020). The maintainer (timvisee) keeps it updated, and there's a separate docker-compose repo with deployment examples.
Winner: Tie. Both have similar community sizes and active maintenance.
Use Cases
Choose PairDrop If...
- You transfer files between your own devices frequently
- You want AirDrop-like functionality across all platforms
- Privacy is paramount — files should never touch a server
- You share files with people on the same network (office, home)
- You want zero-maintenance deployment
Choose Send If...
- You share files with people who aren't on your network
- You need expiring, password-protected download links
- End-to-end encryption of stored files matters
- You're replacing WeTransfer or similar link-sharing services
- You need to control how many times a file can be downloaded
Final Verdict
Use both. They're complementary, not competing. PairDrop replaces AirDrop for local transfers — fast, private, serverless. Send replaces WeTransfer for remote sharing — encrypted links with expiry and download limits.
If you can only pick one: PairDrop for personal/home use (most file sharing happens between your own devices), Send for team/business use (sharing files with clients, partners, or anyone outside your network).
Frequently Asked Questions
Can PairDrop work across different networks?
Yes, but it requires a TURN server (like coturn) to relay WebRTC connections. Without a TURN server, PairDrop only works between devices on the same LAN or VPN.
Are files on Send truly end-to-end encrypted?
Yes. Encryption happens in the browser before upload. The server stores only encrypted blobs. The decryption key is part of the URL fragment (after #), which is never sent to the server.
Can I run both on the same server?
Absolutely. PairDrop uses ~30 MB RAM and zero disk. Send uses ~110 MB RAM plus disk for stored files. They serve different purposes and don't conflict.
What happens when a Send link expires?
The encrypted file is automatically deleted from the server. Neither the file nor its metadata is recoverable.
Top comments (0)