Is browser-based file transfer safe?
Last updated: July 29, 2026
"Send a file through a website" sets off the right instincts. Plenty of file sharing sites do upload your file, keep a copy, scan it, and hand you a link that works for anyone who finds it. It is fair to ask what a browser-to-browser transfer actually does differently, and where the limits are.
This is a plain explanation of the security model — what is protected, by what, and what is not.
The short version
- The file travels encrypted end to end between the two browsers. Encryption is mandatory in WebRTC; there is no unencrypted mode to fall back to.
- The file is never uploaded to a server and never stored. There is no copy to leak, scan, or subpoena later.
- The coordinating server sees metadata — that a session exists, and the file name and size — not the contents.
- A relay server, when one is needed, forwards encrypted bytes it cannot read.
- The realistic risk is not the transport. It is who you give the link to.
What encrypts the file
Browser-to-browser transfers use WebRTC data channels. Before any of your data moves, the two browsers perform a DTLS handshake — the same family of cryptography as the TLS that secures your bank's website, adapted for this kind of connection. They derive keys that only the two of them hold, and every byte afterwards is encrypted with those keys.
The part that matters: the keys are negotiated directly between the two browsers. The coordinating server helps them find each other, but it does not participate in the handshake and never holds a key. This is what "end to end" means in practice — not a promise in a privacy policy, but a property of how the connection is built.
To guard against someone tampering with the introduction, each browser publishes a fingerprint of its certificate as part of the setup, and each side verifies that the peer it ends up talking to presents the matching certificate. A server that tried to insert itself in the middle would have to present a different certificate, and the check would fail.
What the coordinating server can see
Two browsers that have never met cannot find each other unaided. Something has to pass the initial messages between them. On ShareBetweenDevices this is a small server whose only job is to relay those setup messages, and it is worth being precise about what passes through it:
- It sees: that a transfer session exists, the connection details the two browsers need to reach each other (including IP addresses, which is unavoidable for any direct connection), and the file name and size, which the receiving side is shown as the transfer starts.
- It does not see: the contents of the file. Not one byte of file data passes through it.
- It does not keep: the file, because it never has it. Sessions are short-lived and expire on their own.
If the file name itself is sensitive, rename it before sending. That is the one piece of content-adjacent information the coordinating server necessarily handles.
What a relay server can see
Sometimes two devices cannot reach each other directly — strict network address translation, a corporate firewall, mobile networks on both ends. In that case the transfer falls back to a relay, and every byte does pass through a third machine.
Those bytes are still encrypted with keys the relay does not have. It forwards ciphertext. It can see that a connection exists, how much data went through, and for how long. It cannot see what the data is. This is the same reason a relayed transfer is slower but not less private — covered in more depth in why file transfers are slow.
How this differs from cloud file sharing
With a typical upload-and-share service, your file is transmitted to a server, written to disk, and held there until it expires or you delete it. During that window it exists as a readable copy on infrastructure you do not control. It may be scanned for content policy enforcement, backed up to other regions, and retained in logs. The link is often a bearer token: anyone who has it can download the file, and links leak through chat history, screenshots and email forwards.
None of this is a scandal — it is how those services have to work to offer asynchronous delivery. But it is a genuinely different risk profile from a transfer where no copy is ever created.
The trade-off is real and worth stating: a peer-to-peer transfer requires both devices to be online at the same time. You are trading convenience for the absence of a stored copy. If you need to send a file to someone who will pick it up tomorrow, you need a service that stores it. See the comparison with WeTransfer, AirDrop and Send Anywhere.
Verifying the file arrived intact
Encryption protects the file from being read. It does not, by itself, tell you the file arrived complete. ShareBetweenDevices computes a SHA-256 checksum of the file as it is sent and again as it is received, and shows whether the two match when the transfer finishes. A mismatch means the file is corrupt or truncated — send it again rather than trusting it.
Where the real risks are
Being honest about the threat model matters more than reciting encryption acronyms. The transport is the well-solved part. The rest:
Whoever has the link or PIN can receive the file
A transfer link is an invitation. Anyone who opens it first becomes the recipient. Do not post one publicly, and be aware that a PIN read aloud in a shared office is a PIN anyone in earshot can use. Links and PINs expire quickly for exactly this reason, but the window is not zero.
The other device is out of your hands
Once the file is delivered, it is on someone else's machine, subject to their backups, their cloud photo sync, and their security habits. No transfer method changes that.
Your own device
If either device is compromised, encryption in transit is beside the point — the file is readable at both ends by definition. Keep the browser and operating system updated.
Your local network sees that a connection happened
Encryption hides content, not the fact of communication. A network administrator can see that two devices exchanged data and roughly how much.
Practical advice
- Share the link or PIN through a channel you trust, and only with the person receiving the file.
- Rename files whose names would reveal something sensitive.
- Start the transfer while the other person is ready, rather than sending a link for later.
- Check the integrity confirmation when the transfer completes.
- For genuinely sensitive material, encrypt the file itself before sending — an encrypted archive with a password shared separately protects the file at rest on the other device too.
Curious about the mechanics rather than the security model? Read how it works.