Your files. Your machine. Across any network.

True P2P, not "cloud with extra steps"

Most "file transfer" services upload your file to their cloud, then let the recipient download it. That means your bytes sit on their servers — visible to their staff, their backups, court orders, breach notices, and any future policy change.

FileTransferNow works differently. Your file streams directly from your browser to theirs over a peer-to-peer WebRTC connection — even when you're on different continents on different ISPs. No middleman storage step, ever. Delete the tab → the data is gone.

Where your file bytes go

File content is split into 16 KB chunks in your browser, sent over a DTLS-encrypted WebRTC data channel, and written to the recipient's local disk via the Origin Private File System. No byte of your file enters any server we operate — not even when your two browsers are continents apart.

What our signaling server briefly sees

The signaling server (a small Cloudflare Worker + Durable Object) routes only the handshake messages needed to set up the P2P connection — SDP offers, answers, and ICE candidates. These contain network endpoint metadata, not file content. The server holds them in memory just long enough to forward them to the other peer and forgets them when the room is empty.

• No persistent storage. No database.
• No analytics on signaling traffic.
• No room IDs retained after the last peer disconnects.
• Once the P2P connection is established, the signaling server is idle — your transfer would survive even if it crashed.

STUN and TURN — the discovery helpers

To connect across networks, browsers use public STUN servers (like stun.l.google.com) to discover their own public IP, and occasionally fall back to a TURN relay (Cloudflare's free TURN service) when both peers are behind strict NATs.

• STUN sees only your public IP — never your files. Standard internet hygiene; every WebRTC app uses it.
• TURN (only when needed, ~10% of connections) relays DTLS-encrypted ciphertext — Cloudflare cannot decrypt the stream. The encryption keys are negotiated between the two browsers and never leave them.
• If you want zero third-party hop at all, paranoid mode skips STUN, TURN, and our signaling server entirely.

Encryption details

WebRTC data channels are end-to-end encrypted using DTLS 1.2/1.3 with keys negotiated by your browsers. The keys never leave the two endpoints. There is no decryption step server-side — it's mathematically out of our reach.

Resume partials on your disk

If a transfer drops mid-flight, the receiver's browser keeps the partial data in the Origin Private File System (OPFS) so it can resume from the last on-disk byte instead of restarting from 0. These partials live only in the recipient's browser storage, never on a server, and are automatically garbage-collected after 7 days.

Chat messages

The in-app chat panel uses the same DTLS-encrypted WebRTC data channel as your files. Messages are ephemeral — they live only in your two browser tabs. Refresh either tab and the conversation is gone. There is no transcript, no server-side log, no export.

Paranoid mode

Don't trust our signaling server at all? Use the manual SDP exchange on the transfer page. You paste the offer and answer between peers yourself (over Signal, in person, written on paper) and the handshake never touches our infrastructure. Zero servers involved — including ours.

What the website logs

Static page hits to filetransfernow.com may be counted by the hosting CDN for traffic metering. There is no behavioral tracking, no fingerprinting, and no third-party trackers on application pages. If we later add lightweight analytics, it will be privacy-first (no cookies) and disclosed here.

Open source

The full source code — including the signaling server — is open. Audit it, fork it, or self-host the signaling layer for maximum control.