— Architecture brief

How Beamdrop works.

Beamdrop is built on a single principle: only the sender and recipient should have access to the file.

1. Discovery

When you open Beamdrop, you join a room with others sharing your public IP address, usually on your home or office Wi-Fi. The room name is generated by hashing your IP with a server secret using HMAC-SHA-256, making it unguessable to outsiders.

On mobile networks, IPv6, VPNs, or carrier-grade NAT, where strangers may share an IP address, Beamdrop does not auto-pair. Instead, it recommends using a QR code or six-character code.

2. Signalling

Two browsers cannot communicate directly until they exchange WebRTC connection information, such as SDP offers, answers, and ICE candidates. Beamdrop uses a lightweight Cloudflare Worker to relay these messages between peers in the same room. The Worker:

• Holds nothing in persistent storage.
• Logs nothing about message contents, IPs, or user agents.

3. Transfer

Once both peers have established a connection, the file streams over a WebRTC RTCDataChannel. Every byte is encrypted with DTLS, the protocol that secures HTTPS, with keys negotiated directly between the browsers.

The receiving browser writes data to disk as it arrives using the File System Access API, or a streaming fallback if unsupported. Files of any size, including multi-gigabyte transfers, are supported because nothing is buffered in memory.

4. Verification

To prevent impersonation, both devices display a Short Authentication String: a five-emoji and six-digit code derived from the negotiated DTLS fingerprints. If the codes match on both screens, the channel is verified as end-to-end encrypted.

What we don't do

• We do not run analytics, telemetry, or A/B tests.
• We do not set cookies except those strictly required for a working session.
• We do not have user accounts, so we cannot lose, sell, or be compelled to disclose them.
• We do not store files and never have access to them.