How TransferFiles.net works

The core idea: peer-to-peer

Every traditional file-sharing service (WeTransfer, Google Drive, Dropbox) works the same way. You upload your file to their server. The receiver downloads it from that server. The company pays for bandwidth and storage, which is why they charge for large files.

TransferFiles.net works differently. We use a technology called WebRTC (Web Real-Time Communication) to create a direct connection between your browser and the receiver's browser. Your file goes straight across, device to device. It is never uploaded to or stored on a server.

What is WebRTC?

WebRTC is an open standard built directly into Chrome, Safari, Firefox, and Edge. It was originally designed for video calling (it powers Google Meet and WhatsApp Web). We use the same technology to stream file data instead of video. Every transfer is encrypted using DTLS-SRTP, the same standard used for encrypted video calls. This is automatic and cannot be disabled.

What happens when you send a file

1. You pick a file. It stays on your device. Nothing uploads anywhere.
2. A session code is generated. Your browser registers a random short code with a signaling (broker) server, the open-source PeerJS service. The code and link are all the broker needs. The file itself is never sent to it.
3. You share the link or code with the receiver via WhatsApp, email, Slack, or any app.
4. The receiver opens the link. Their browser looks up the code on the broker, which passes connection details (such as network addresses) between the two browsers, then steps aside.
5. A direct encrypted tunnel opens between the two browsers. Our server is no longer involved.
6. The file streams across in chunks of a few hundred kilobytes, which grow automatically on fast connections, from your device to the receiver's Downloads folder.

Why both tabs must stay open

Because your device is the source of the file, not a server. If you close your tab, the stream stops. This is the trade-off that makes the service free, private, and unlimited in size.

What about firewalls?

Most connections allow direct peer-to-peer. When a strict firewall blocks it, WebRTC automatically falls back to a relay server that passes the encrypted data without being able to read it.

Is it really private?

The broker only handles the session code and connection details. The file, its name and its contents travel inside the encrypted connection between the two browsers, and we have no copy of any of it. If a relay server is needed because of a strict firewall, it forwards encrypted data that it can't read and doesn't store.

Why is it free?

We have no storage costs and no bandwidth costs. The connection is set up by a lightweight signaling service, and relays are only used when a direct path isn't possible. We keep it free through ads shown on the page.