OnionShare is a free, open-source tool created by Micah Lee, with contributions from a community of developers, and used in newsrooms where moving a sensitive document without a third party in the loop actually matters. It is built on Tor's onion services — the same technology that lets a website be reachable only through the Tor network at a .onion address — but it flips the usual relationship. Instead of visiting someone's hidden service, you become one, for as long as the transfer takes.
How the no-middle-server model works
When you drop a file into OnionShare and start a share, the tool spins up a small web server bound to your own computer and publishes it as an onion service through Tor. It generates a random .onion address and, by default, a private key or password that the recipient also needs. You send that address (and credential) to your recipient over some channel, they open it in Tor Browser, and they download the file directly across the Tor circuit between their machine and yours.
There is no upload step to a company. No account. No file sitting on infrastructure you do not control, waiting to be subpoenaed, breached, or retained past its usefulness. When you close OnionShare, the onion service disappears and the address stops resolving.
The data lives only on the sender's device and is transferred peer-to-peer through Tor. There is no intermediate host that holds a copy, which means there is nothing for a third party to log, leak, or hand over. The trade-off: your computer must stay online and running OnionShare for the duration of the transfer.
More than file sending
OnionShare ships several modes, all built on the same onion-service foundation:
- Share — send files or folders to one or more people. You can require the recipient's credential and optionally shut the service down automatically after the first download.
- Receive — the reverse: you publish an onion address that acts as a secure drop box, letting others upload files to you. This is the pattern a journalist might hand to a source.
- Host a website — serve a static site over an onion address straight from a folder on your disk, with no hosting provider involved.
- Chat — an ephemeral, anonymous chat room that exists only while the service is running and keeps no history once it stops.
What OnionShare protects — and what it doesn't
The anonymity and no-third-party properties are real, but they sit inside specific limits. It is worth being precise.
| Protects against | Does not protect against |
|---|---|
| A cloud provider holding or logging your file | A compromised endpoint — malware on either device sees the plaintext |
| Network observers learning the file contents (Tor encrypts the circuit) | Someone who obtains both the .onion address and the private key/password |
| Linking the transfer to your real IP address (Tor hides it) | Metadata inside the file — see document properties and EXIF data |
| A persistent record after you close the app | An insecure channel used to send the address — that link leaks if intercepted |
That last row is the operational catch. OnionShare protects the transfer, but you still have to deliver the .onion address and its credential to your recipient somehow. If you paste them into an unencrypted email or SMS, an adversary watching that channel gets everything they need. The address should travel over an end-to-end encrypted path — which is exactly the kind of out-of-band delivery problem secure messaging exists to solve.
A good habit before sharing any document: strip its metadata. A PDF or photo can carry author names, GPS coordinates, software versions, and revision history that survive the most careful anonymous transfer. See: document metadata privacy
When OnionShare is the right tool
OnionShare shines for one-off, sensitive transfers where you want zero third-party custody and strong sender/receiver anonymity: a source sending documents to a reporter, a researcher moving data they cannot trust to a cloud, anyone in a context where the existence of an upload is itself risky. It is overkill for sharing vacation photos with family, and it requires both parties to use Tor — friction that is the point, not a bug.
For ongoing, conversational communication rather than discrete drops, a dedicated encrypted messenger is the better fit. The tools are complementary: OnionShare for the metadata-resistant handoff, an E2EE app for the relationship around it. If you want the surrounding context, our guides on secure file sharing and whistleblower opsec cover the workflow OnionShare slots into.
How Haven thinks about it
We admire OnionShare for the same reason we built Haven the way we did: the strongest privacy comes from removing the trusted middle party, not from promising to be a trustworthy one. Haven keeps message contents end-to-end encrypted and treats metadata as a liability to minimize rather than a resource to mine. Different tool, same instinct — the architecture should not require you to trust us with what you do not have to.