# PairDrop vs Send: Local or Link-Based Sharing?

## 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](https://github.com/schlagmichdoch/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](https://github.com/timvisee/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.

```yaml
# 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.

```yaml
# 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](https://github.com/timvisee/send-docker-compose) 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.

## Related

- [How to Self-Host PairDrop](/apps/pairdrop/)
- [How to Self-Host Send](/apps/send/)
- [Send vs WeTransfer](/compare/send-vs-wetransfer/)
- [Self-Hosted Alternatives to AirDrop](/replace/airdrop/)
- [Self-Hosted Alternatives to WeTransfer](/replace/wetransfer/)
- [Best Self-Hosted File Sharing Tools](/best/file-sharing/)
- [Docker Compose Basics](/foundations/docker-compose-basics/)