Privacy Policy
The short version
Files go directly from your device to theirs, end to end encrypted, and are never uploaded to or stored on a server. Our infrastructure sees a random session id and connection descriptors. It never sees file names, sizes, or contents, and it cannot decrypt anything even if it captured every byte.
What our signaling server sees
To connect two browsers, each one opens a short-lived connection to a small service we run on Cloudflare Workers. That service sees:
- •A random 128-bit session id from the link, which identifies the pairing and nothing else.
- •Connection descriptors (WebRTC session descriptions and ICE candidates), which include the IP addresses each browser can be reached at. These are forwarded to the other browser and are not logged.
- •Whether the connection succeeded, expired, or was refused, as an aggregate counter with no identifiers attached.
It never sees file names, sizes, types, contents, or the encryption key. The session is destroyed the moment the two browsers connect, or after 20 minutes if nobody opens the link.
Encryption
Everything that crosses the connection is encrypted twice:
- •By WebRTC itself (DTLS), which is mandatory and not something we could turn off.
- •By a random 256-bit key generated in the sender's browser and placed in the link after the # sign. Browsers do not send that part of a URL to any server, so the key never reaches us, Cloudflare, or anyone reading logs. Every piece of every file is encrypted with it (AES-GCM) before it is sent and verified on receipt.
Anyone who has the full link can receive the files, once. Treat the link like the files themselves.
When a relay is used
Some networks block direct connections between devices. When that happens, the encrypted traffic is routed through a relay (Cloudflare TURN) so the transfer can still complete. About the relay:
- •It carries ciphertext only. It does not have the key and cannot read the files.
- •Relayed transfers are capped at 2 GB. Direct transfers are not capped.
- •The page shows when a connection is relayed.
IP addresses
Peer to peer means the two devices talk to each other. To do that, each browser learns the other one's IP address. This is inherent to WebRTC and we cannot prevent it. If that matters to you, use a VPN on your side or share the link only with people you would share your IP address with.
Analytics
If you accept the cookie banner, we load Google Analytics to count visits and a handful of events:
- •That a link was created, a transfer started, completed, or failed, and the failure stage: counts only.
- •Whether a connection was direct or relayed, so we can plan relay costs.
- •Page views, browser and device type, and country-level region.
No event ever includes a file name, size, type, session id, or the link. If you decline, nothing is loaded.
Cookies and local storage
- •One local storage entry remembers your analytics choice.
- •On some browsers, received files are written to the browser's private origin storage while they arrive, then handed to you as a download and deleted. They never leave your device.
- •No other cookies are set by us.
Third parties
- •Netlify hosts this website.
- •Cloudflare runs the signaling service and the TURN relay described above.
- •Google Fonts serves the typeface.
- •Google Analytics, only with your consent.
None of them receive file contents or the encryption key.
Data retention
- •We retain zero file data, because we never have it.
- •Signaling sessions are deleted at connection time or after 20 minutes.
- •Aggregate counters and analytics are kept as statistics with no identifiers.
Your rights
Because we do not collect personal data through the tool, there is nothing for us to export or delete on request. If you have accepted analytics and want that data handled, the Google Analytics controls apply. Questions are welcome at the address below.
Contact
Privacy questions go to hello at thejust dot network, or use the feedback button on any page.
Last updated: September 2026