Initializing secure environment…
Initializing secure environment…
Send a file straight from your browser to another browser, with no server in the middle. A share code is generated, the other person enters it, and the two tabs connect directly and transfer the bytes. Nothing is stored anywhere, because there is nowhere to store it, and the connection is encrypted in transit. Free, no account, no upload, no size limit beyond what both devices can hold in memory.
Send any file straight to another browser — no server upload, no account, 100% private. A share code connects the two peers directly over WebRTC. Free, with no size limit beyond your device's memory.
A peer-to-peer transfer leaves no copy on any server, which is a different and stronger property than 'the server deletes it after an hour'. For a document under an NDA, a medical record or anything with a compliance requirement, that difference is often the whole point.
Symmetric NAT on either side, or a corporate firewall, means the two peers cannot address each other directly. No web page can get around that, because the restriction is in the network rather than the software. The clear error message is the point — a tool that hangs while it retries is worse than one that tells you the network is the obstacle.
Compare the fingerprint shown on both screens. Matching hashes mean the bytes are identical, which catches a truncated transfer on a large file. This is the same verification as fingerprinting a document before and after sending it, applied to a channel where the risk is corruption rather than interception.
Keep it to one instruction: here is a link, enter this code. There is no account to create and nothing to install, which is what makes this workable across a family or across a client's staff. The alternative tools all require the recipient to sign up, and that is where most attempts at sharing actually fail.
No. The two browsers connect directly to each other, and the file streams across that connection. What a server may handle is the signalling — the initial handshake that lets two peers find each other. It never sees the file, and the design is specifically built so that is true.
The connection is encrypted in transit, which is a property of WebRTC and applies to every peer-to-peer transfer. The file itself is not separately encrypted by this tool, so the guarantee is about the connection rather than about the file's contents. For a file that must be encrypted at rest as well, encrypt it first with Encrypt PDF and send the password separately.
Some corporate networks and some symmetric NATs prevent a direct connection, and no browser tool can bypass that — it is a network policy, not a bug. The failure is reported clearly rather than hanging, and the practical alternative is the method you were avoiding in the first place.
No limit of our own. The real limit is the memory of both devices, since a chunked transfer needs the whole file available to read from. A large file on a phone is the constraint, not a policy in the code.
It is valid while your tab is open, and it stops working when you close it. There is no stored session to expire later, because nothing is stored — which also means nobody can retrieve a link to your file after the fact.
Yes, as a set, or send a file and then send another with a new code. Large transfers are chunked and resent as needed, so a dropped connection resumes rather than starting again.
A hash of the file, shown on both sides. If it matches on both, the file that arrived is the file that was sent — the same property that makes a document fingerprint useful, applied to a transfer where corruption is the concern.
Yes. No account, no storage, no upload and no watermark. There is nothing here for anyone to sell, which is why it costs nothing.
More collaborate & share — all free, no upload.