Do I need to install anything?

No. Everything — the transfer engine, encryption, verification — is built into modern browsers via WebRTC. Chrome, Edge, Firefox, and Safari all work, on desktop and mobile.

Can the relay read my files?

No. The relay (TURN) only forwards packets. The DTLS encryption is negotiated directly between the two browsers, and the keys never leave them — so the relay sees encrypted bytes it cannot decrypt.

Why a 6-digit code instead of just a link?

Both work. The code is easy to read out over a phone call; the share link and QR code do the same job in one tap. Either way, it expires with the transfer.

What data do you keep after a transfer?

Only what coordination required: the session record — file names and sizes — until it expires, plus anonymous aggregate counters for the public stats. Never file contents; on the direct path there are none to keep.

Can someone intercept the transfer?

They would have to break DTLS — the same standard that protects HTTPS — using keys that exist only inside the two browsers for that session. An optional password adds another gate before any file metadata is even released.

Why WebRTC instead of plain HTTPS uploads?

HTTPS uploads put a server in the middle: your file crosses the internet twice and lands on storage. WebRTC DataChannels let browsers talk directly — one hop, no storage — while the protocol handles the messy networking (NAT traversal, reconnects) for us.

The complete technical story

How files travel browser to browser

No installs, no cloud hop, no storage bucket. This is the complete journey of a file — the handshake, the encrypted stream, and what our servers do (and never do).

Send files now Large-file guide

3 min read
DTLS end-to-end
No storage

The journey of a file

Three phases, from matchmaking to clean teardown.

The handshake
seconds
Two strangers on the internet become peers. The server’s only job is the introduction.
You pick files
File metadata — names, sizes, types — is registered with the coordination server. Never the contents. You get a 6-digit code, a share link, and a QR code.
They enter the code
The recipient’s browser asks the server for an introduction. If you set a password, it’s checked first — stored only as a salted hash — before any metadata is released.
Browsers get introduced
Over a signaling channel, the two browsers exchange connection candidates (SDP offer/answer and ICE candidates). The server is the matchmaker — it passes messages, not files.
An encrypted channel opens
WebRTC negotiates DTLS — the same encryption family that protects HTTPS — with fresh keys that exist only inside the two browsers.
The transfer
minutes to hours
Bytes flow peer to peer, in order, with receipts — the boring reliability of a courier, at network speed.
Files stream in chunks
Each file is read from disk in chunks of up to 64 KiB and pushed over the DataChannel. Memory use stays flat, whether the file is 10 MB or 10 TB.
Every chunk is confirmed
Each chunk carries a CRC-32 and the receiver ACKs progress in batches. The sender paces itself on the receiver’s buffer — fast links fly, weak links stay stable.
Drops don’t restart
If the connection breaks, both sides reconnect and the receiver asks to resume from its last confirmed chunk. Files already verified are skipped entirely.
SHA-256 seals the deal
Both sides hash the bytes as they flow. At completion the digests must match — or the transfer fails loudly rather than deliver corruption.
The teardown
on your schedule
Delivery is confirmed, the session expires, and there is nothing left to clean up.
Delivery confirmed
The receiver’s browser saves each verified file to disk — individually, or as a single ZIP when the total is under 4 GB.
The session expires
Coordination metadata lives exactly as long as you choose: 1 hour to 7 days, 24 hours by default. Then it’s deleted.
Nothing lingers
On the direct path, file bytes never existed on any server. There’s nothing to breach because there’s nothing stored.

What our servers actually see

A coordination server has to see something to coordinate. Here is the whole inventory — and the rest of the story.

Coordinates

Ephemeral, functional, deleted with the session.

The 6-digit code, its expiry, and when it was used
File names, sizes, and types — the manifest the receiver sees
Connection events for the session log (joined, completed, cancelled)
Anonymous aggregate counters for the public stats — numbers, never contents

Never touches

The parts that stay between you and your recipient.

File contents, on the direct path — bytes go browser to browser
DTLS encryption keys — they live only in the two browsers
Your password — only a salted hash is ever stored
An account or a profile — there are none

Every claim above, in legally binding form — our Privacy Policy

Two paths, always labeled

Networking is messy. We don’t hide it — we label it.

Direct P2P

The default

Browsers connect straight to each other.

The two browsers find a direct route through NAT and firewalls (STUN/ICE) and connect peer to peer.
File bytes travel only between the two devices — no third party is in the path.
The connection badge in the app shows Direct P2P the whole time.

Secure relay

The fallback

For networks that block direct links.

Strict corporate firewalls and symmetric NAT sometimes make a direct connection impossible.
Traffic then flows through a TURN relay — but DTLS encryption stays end-to-end between the browsers, so the relay forwards bytes it cannot read.
The badge honestly switches to Secure relay so you always know the path.

We label the path on every transfer because you deserve to know — not every service tells you.

Under the hood

The nerdy corner — the five mechanisms doing the heavy lifting.

protocol: A compact binary protocol over WebRTC DataChannels: 23-byte chunk headers with per-chunk CRC-32, batched acknowledgements, and explicit resume requests after reconnects.
chunking: Chunks sized to what the network path allows (up to 64 KiB). The sender pauses when its buffer fills and resumes when it drains — backpressure, the boring kind of clever.
integrity: Incremental SHA-256 on both sides, compared at completion. Verified files are marked and never re-sent after a reconnect.
telemetry: During a transfer, both browsers sample real WebRTC statistics — throughput and round-trip time. The charts in the app are measured, never estimated.
expiry: Sessions live 1 hour to 7 days (24 hours by default). Expired sessions are deleted; the file bytes were never stored in the first place.

How-it-works questions

The questions curious people ask before their first transfer.

Now you know how it works. Try it.

Pick a file, share a code, and watch the telemetry chart draw itself from real stats.

Send files now

No install · no account · keep your tab open