Clacify

File Transfer

Send any file up to 10 GB directly to another device — P2P, zero server storage, 100% secure

Built & maintained by Pappu Venkata Subbi Reddy, founder of Clacify · Updated August 2026

About File Transfer

File Transfer sends a file directly from one browser to another using WebRTC — a real peer-to-peer connection negotiated over a lightweight signalling channel, with a Cloudflare Worker relay as an automatic fallback for the connections that can't establish P2P directly (common behind strict corporate firewalls or symmetric NAT). Pick a file, get a shareable link and a 25-character code, and once the receiver opens it, the two browsers attempt to open a direct WebRTC data channel; if that succeeds within about 12 seconds, the file streams device-to-device without ever passing through a server. If it doesn't, the transfer automatically falls back to streaming the same file through an encrypted WebSocket relay, chunk by chunk, without the relay ever writing the file to disk. Either way, the session expires after 15 minutes by default (extendable up to a 45-minute cap), and there's no account, no upload step, and no hard file-size limit built into the tool itself.

Why Use File Transfer?

How It Works

The sender first requests a room from the transfer server, gets a code, and shares a link. When the receiver opens it, both sides connect over a WebSocket for signalling. The sender then tries to establish a real WebRTC RTCPeerConnection using public STUN servers only (no TURN relay, since that would cost ongoing bandwidth) — this works whenever both sides' networks allow a direct connection to be negotiated. If a direct data channel opens within roughly 12 seconds, the file is sent over it in 256 KB chunks with back-pressure (pausing whenever the channel's send buffer exceeds 8 MB) — true browser-to-browser transfer, invisible to any server in between. If the P2P attempt times out — common on networks with symmetric NAT or restrictive firewalls, since STUN alone can't traverse every network topology — the tool falls back to sending the file over the original WebSocket connection in 4 MB chunks instead, relayed through a Cloudflare Worker running at the network edge; the file streams through that relay without ever being written to its disk. On the receiving end, if the browser supports the File System Access API (Chromium-based browsers), files over 100 MB are written straight to a location you choose on disk as chunks arrive, rather than being buffered entirely in memory first — important for files too large to comfortably hold in RAM. A visible countdown timer (15 minutes initially) closes the session if no transfer starts in time, and can be extended twice by 15 minutes each, to a 45-minute cap.

What "P2P with a fallback" actually means here

True peer-to-peer only works when both browsers' networks allow a direct connection to be negotiated via STUN, which handles most home and mobile connections but not every network — symmetric NAT setups and some corporate firewalls block it outright, and this tool doesn't run a TURN relay (a paid relay service that guarantees a P2P-equivalent connection even through the hardest NAT types) to force a workaround, since that would mean routing every failed-P2P transfer through paid bandwidth. Instead, it falls back to the same Cloudflare Worker relay used for signalling — so the transfer still completes, just via a relay rather than a direct connection. Either path is TLS-encrypted in transit and the relay never persists the file to disk.

Why large files ask you to "choose a save location"

For files under 100 MB, the tool assembles the download in memory and offers it as a normal browser download when complete. For anything larger, if your browser supports the File System Access API, it instead asks you up front to pick a save location and writes each chunk to that file as it arrives — this avoids holding a multi-gigabyte file entirely in RAM, which could otherwise crash the tab on a memory-constrained device. Browsers without that API (notably Safari and Firefox, at least as of this writing) fall back to the in-memory approach regardless of file size.

The session timer, and why it exists

A transfer session starts with a 15-minute window for the receiver to open the link and for the transfer to begin, extendable twice in 15-minute increments to a 45-minute maximum — long enough for a receiver to notice a notification and open a link, but not indefinite, since an open room otherwise sits waiting on the relay server for no reason. If the timer runs out before a transfer starts, the session simply expires and the sender needs to start a new one; a transfer already in progress isn't interrupted by the countdown reaching zero.

Frequently Asked Questions

How does peer-to-peer file transfer work?

P2P file transfer connects two browsers directly using WebRTC. One sender generates a room code; the receiver enters the same code on their device. A direct data channel opens between the two browsers — your file travels directly from your device to theirs without passing through any server. Speed equals your network connection speed.

Is peer-to-peer file transfer secure?

Yes. WebRTC data channels are encrypted end-to-end using DTLS-SRTP (the same encryption used for secure web video calls). Files are never stored on any server — if the connection drops before completion, no partial file remains anywhere except the two devices. This makes P2P more private than email or cloud storage file sharing.

Sources & references

Related PDF & Office Tools