unsubbed.co

OnionShare

OnionShare is a Python-based application that provides and anonymously share a file of any size.

Open-source tool for file sharing, anonymous website hosting, and private chat using the Tor network, honestly reviewed.

TL;DR

  • What it is: Open-source desktop app that turns your own machine into a temporary Tor hidden service — for sharing files, receiving uploads, hosting static websites, or running private chats [1][2].
  • Who it’s for: Journalists, activists, security-minded individuals, and anyone who needs to transfer files without routing data through a third-party server. Also useful for non-technical founders who want to share sensitive documents without trusting WeTransfer, Dropbox, or Google Drive with the contents [1][3].
  • Cost savings: $0, always. No SaaS tier. No per-GB fee. No account required. The comparison isn’t Zapier-vs-self-hosted — it’s “file goes through a corporate server” vs. “file goes directly to the recipient via Tor” [2][3].
  • Key strength: True anonymity and no infrastructure to maintain. Your ISP sees Tor traffic but not what you’re sharing or with whom. No sign-up, no cloud dependency, no recurring bill [1][2].
  • Key weakness: Speed. Tor adds latency and limits throughput — large files are painful. Recipients must use Tor Browser or Brave. The .onion address disappears when you close the app unless you explicitly save it as persistent [2][3].

What is OnionShare

OnionShare is a desktop application that uses the Tor network to create temporary (or persistent) hidden services directly on your computer. When you share a file, OnionShare doesn’t upload it anywhere — it runs a local web server, wraps it in a Tor hidden service, and hands you a .onion URL to give to the recipient. The recipient opens that URL in Tor Browser and downloads directly from your machine [1][2].

The project was created by Micah Lee, a security researcher and journalist. It sits at 6,915 GitHub stars. The software runs on Windows, macOS, and Linux, and is available via Homebrew on macOS and as a Flatpak or Snap on Linux [GitHub README].

There are four distinct modes:

  1. Share: Send files to someone. You get a .onion link. They open it in Tor Browser and download. The service can auto-stop after the first download, or stay open for multiple recipients.
  2. Receive: Accept files from others. You give someone your .onion address and they upload to you — without either party exposing their IP address [1].
  3. Host Website: Serve a static site (HTML, CSS, JS) directly from your computer via an .onion address. No domain registration, no ISP permission, no port forwarding [1].
  4. Chat: Run an ephemeral chatroom. No logs, no server, no accounts — just a .onion address that participants open in Tor Browser [1].

The project describes itself plainly: “Securely and anonymously share files, host websites, and chat with friends using the Tor network.” That’s accurate and there’s no inflated marketing layer around it [GitHub README].


Why people choose it

The case for OnionShare isn’t about convenience — it’s about threat models and data sovereignty.

The ISP/port-forwarding problem. Most home internet contracts explicitly prohibit running servers. Even if yours doesn’t, forwarding ports, configuring a router, setting up dynamic DNS, and securing a web server is a multi-hour project. OnionShare skips all of this by routing through Tor. Your ISP sees you’re using Tor; it can’t see what you’re serving or to whom [1]. For the self-hosting crowd that wants to publish a small personal site or share files without buying a VPS, OnionShare is the zero-friction path.

No third-party server in the chain. Every mainstream file transfer service — WeTransfer, Google Drive, Dropbox, even Proton Drive — puts a corporate server between sender and recipient. The files pass through infrastructure you don’t control, are subject to subpoenas, terms of service changes, and data breaches [2][3]. OnionShare’s peer-to-peer architecture means the file never touches a server you don’t own.

Versus WeTransfer, Send, and similar tools. The comparison from AlternativeTo users consistently puts OnionShare in the same feature space as Firefox Send (discontinued), Uguu.se, and similar ephemeral hosting tools [4]. The difference is that those services still use a central server. OnionShare is peer-to-peer: the only infrastructure is the Tor network itself, which is distributed by design [2][3].

Versus Syncthing. Syncthing is the better tool for ongoing, bidirectional sync between devices you control. OnionShare is the better tool for a one-time transfer to someone else — especially when that someone else shouldn’t know your IP address, or when you don’t want to exchange Syncthing device IDs and maintain a persistent connection [2].

The decentralization angle. Ernst Renner’s write-up [1] frames OnionShare’s website-hosting mode as a small act of infrastructure independence: no ICANN, no DNS registrar, no hosting provider. The .onion address is generated cryptographically when you start the service — it’s free, it belongs to no registry, and it’s valid as long as your machine is running. For experimenters and privacy advocates, this matters beyond the practical utility.


Features

File sharing (send mode):

  • Select one or more files or folders, click Start. OnionShare generates a .onion URL with an optional password [1][2].
  • Auto-stop after first download (default) or leave open for multiple recipients.
  • The recipient sees a simple web interface in Tor Browser and downloads directly.

File receiving:

  • Create a receive-mode service, give recipients your .onion address.
  • They upload files to you through a browser form — no accounts, no exposure of their IP or yours [1].
  • Useful for journalists receiving source documents without exposing drop location.

Anonymous website hosting:

  • Drop a folder of static HTML/CSS/JS into OnionShare, click Start.
  • Your site is live at a .onion address. Accessible via Tor Browser and Brave [1].
  • Persistent mode: save the tab so the same .onion address returns on restart [1].
  • No HTTPS certificate management — Tor itself provides the transport-layer security.

Private chat:

  • Ephemeral chatroom with no logs and no server outside your machine.
  • Multiple participants connect via the .onion URL in Tor Browser [1].
  • Closes when you stop the service; no message history persists anywhere.

CLI mode:

  • Full command-line interface alongside the GUI — useful for scripting or headless servers [GitHub README].

Cross-platform:

  • Windows installer, macOS app (also via Homebrew), Linux Flatpak and Snap [GitHub README].

What it doesn’t do:

  • Real-time sync (use Syncthing for that).
  • Large-file transfers at speed (Tor throttles throughput significantly) [2][3].
  • Host dynamic server-side applications — static sites only in website mode.
  • Persist automatically — if your machine shuts down, the service is gone unless you saved a persistent tab [2][3].

Pricing: SaaS vs self-hosted math

OnionShare has no SaaS model. The software is free. The “server” is your own computer. There is no subscription, no per-GB charge, and no account to create.

The relevant cost comparison is against the paid tiers of mainstream file transfer services:

ServiceFree tierPaid tier
WeTransfer3 GB/month, files expire in 7 days~$12/mo for 1 TB, custom branding
Proton Drive1 GB free€3.99/mo for 200 GB
Send (Internxt fork)5 GBvaries
OnionShareUnlimited, files never leave your machine$0

The catch: “unlimited” comes with the constraint that your machine must stay online for the duration of the transfer. If you’re sending a 20 GB video folder, your laptop has to stay awake until the recipient finishes downloading — which over Tor could take hours [2][3].

For a non-technical founder transferring sensitive documents to a lawyer, accountant, or investor: OnionShare saves whatever you’d spend on a privacy-tier cloud storage plan. The trade-off is Tor’s speed penalty and the requirement that the recipient can open a .onion URL. If your recipient is comfortable using Tor Browser or Brave, the tool costs nothing. If they aren’t, you’re back to email or cloud storage.


Deployment reality check

“Deployment” is almost a misleading word here — OnionShare installs like any desktop app.

What you need:

  • A desktop or laptop running Windows, macOS, or Linux.
  • OnionShare installed (installer from the website, Homebrew, Flatpak, or Snap) [GitHub README].
  • The app downloads and configures Tor automatically — you don’t set up a Tor daemon yourself.
  • Tor Browser or Brave on the recipient’s side [1].

What can go sideways:

The speed problem is real and worth stating plainly. Tor is not designed for throughput — it’s designed for anonymity. Every packet bounces through three relays. File transfers that would take seconds over a direct connection can take minutes or hours over Tor for large files [2][3]. This is not an OnionShare bug; it’s Tor’s fundamental architecture.

The recipient friction is also real. Sending a .onion URL to a non-technical person and explaining that they need to install Tor Browser first is a meaningful UX barrier. The comparison sites consistently list “Recipients need a Tor-enabled browser to access shared content” as a top limitation [2][3]. If your recipient balks at installing Tor Browser, OnionShare doesn’t work for that use case.

The ephemeral nature is a feature and a footgun simultaneously. By default, closing the OnionShare tab destroys the .onion address. The persistent-tab feature saves it, but if you forget to enable it and close the app mid-transfer, you’ll generate a new address on restart [1][2]. For the website-hosting use case specifically, this matters: anyone who bookmarked the old .onion link will get a dead address.

Running OnionShare on a spare machine for persistent hosting — the setup Ernst Renner describes [1] — requires that machine to stay on and connected. A 30W mini PC costs roughly $2–3/month in electricity at typical rates, which is cheaper than any hosting plan but requires the physical hardware investment upfront.


Pros and cons

Pros

  • No third-party server. Files go from your machine to the recipient’s. Nothing is stored on external infrastructure at any point [2][3].
  • True anonymity. Neither party exposes their IP address. Your ISP sees Tor traffic but not content or direction [1][2].
  • Zero cost. No account, no subscription, no per-GB fee [2][3].
  • Zero infrastructure. Tor handles routing automatically — no port forwarding, no DNS, no reverse proxy [1].
  • Four useful modes in one app. Share, receive, host, chat — without needing four separate tools [1].
  • No recipient account required. Anyone with Tor Browser can receive files from you.
  • CLI support. Scriptable for power users [GitHub README].
  • Persistent mode. Stable .onion addresses when you need them [1].
  • Actively maintained. 6,915 stars, active CI pipeline [GitHub].

Cons

  • Tor is slow. Large file transfers are genuinely painful. This is not fixable within the current architecture [2][3].
  • Recipient must use Tor Browser or Brave. Sending a .onion link to someone who has never heard of Tor adds friction [1][2][3].
  • Your machine must stay on. Unlike cloud storage, the service is gone if your computer sleeps, loses power, or loses connectivity [2][3].
  • Ephemeral by default. The .onion address changes on each session unless you explicitly enable persistence [1][2].
  • Static hosting only. No server-side code, no databases — the website mode works for HTML/CSS/JS portfolios and documentation, not dynamic apps [1].
  • License field unverified in profile. The merged data shows “NOASSERTION” for the license, which typically indicates a parsing failure rather than a licensing problem. The project is open source and publicly available, but double-check the repository directly if license status matters for your use case.
  • Not for high-volume transfers. If you routinely send multi-gigabyte files to clients on tight deadlines, Tor’s latency makes this impractical [2][3].

Who should use this / who shouldn’t

Use OnionShare if:

  • You’re a journalist, researcher, or lawyer transferring sensitive documents and you can’t afford the risk of a third-party server seeing the contents.
  • You want to share files anonymously — neither party should know the other’s IP address.
  • You need to set up a simple receiving drop box (journalist tip line, anonymous feedback form) without running a server.
  • You want to publish a small static site without paying for hosting, dealing with DNS, or registering a domain.
  • Your recipient is technically comfortable enough to open a .onion link in Tor Browser.
  • The files you’re sending are small to medium in size (under a few hundred MB).

Skip it if:

  • Your recipient has never heard of Tor and won’t install Tor Browser. The barrier to entry will kill the use case before it starts.
  • You’re regularly sending large files (multi-GB video, design assets, database backups). Tor speeds make this impractical [2][3].
  • You need the transfer to complete while your laptop is closed. The host machine must stay running [2][3].
  • You want a permanent hosting URL that stays live without a running machine. OnionShare is not a replacement for a VPS or a CDN.
  • Your use case is file sync between your own devices — use Syncthing instead [2].

Alternatives worth considering

  • Syncthing — better for ongoing sync between devices you own. No anonymity guarantees, but reliable and fast [2].
  • FilePizza — browser-based peer-to-peer transfer with no Tor dependency. Simpler for non-technical recipients, but no anonymity [3].
  • Send (Internxt / various forks of Firefox Send) — centralized temporary hosting with end-to-end encryption. Easier for recipients, but a server is still in the chain [4].
  • Proton Drive — encrypted cloud storage from the same company as ProtonMail. Trustworthy, compliant with Swiss privacy law, but still a cloud server you don’t control.
  • Briar — for messaging and file sharing in high-threat environments; also Tor-based, mobile-first.
  • SecureDrop — the hardened, institutionally deployed version of this concept. Built for newsrooms receiving sensitive leaks. More setup, higher assurance, not a desktop app. Worth knowing about if OnionShare’s threat model isn’t strong enough for your situation.

For a non-technical founder who just wants to stop routing sensitive documents through Gmail attachments: the realistic comparison is OnionShare vs. Proton Drive. Proton Drive is easier (no Tor Browser requirement for recipients), still encrypted, and has a reasonable free tier. OnionShare wins on anonymity and zero server dependency. Pick based on how much you trust a Swiss cloud provider vs. how much friction you’re willing to add for your recipient.


Bottom line

OnionShare solves a narrow problem extremely well: sending files, receiving uploads, hosting static content, or chatting — without trusting a third-party server, without exposing IP addresses, and without spending money. It’s not a general-purpose Dropbox replacement. It’s a specific tool for situations where “this file cannot go through their servers” is the actual requirement, not just a preference.

The Tor speed limitation is real and non-negotiable. If you’re sending a 10 MB PDF to a lawyer, OnionShare is fine. If you’re sending a 20 GB video project to a client with a deadline, it isn’t. Know which use case you’re in before you recommend this to someone who will then try to transfer a video archive over Tor and conclude the tool is broken.

For the self-hosting crowd: the website-hosting mode is genuinely interesting for small personal projects and prototypes that don’t need a custom domain or production uptime guarantees. The $0 cost and zero infrastructure requirement make it worth knowing about. For everything that needs to be reliably up 24/7 with a real URL — you still want a VPS. That’s exactly what upready.dev deploys for clients who’ve outgrown the “my laptop has to stay on” constraint.


Sources

  1. Ernst Renner“Decentralized Hosting Made Simple: OnionShare on MX Linux”. https://ernstrenner.com/decentralized-hosting-made-simple-onionshare-on-mx-linux/
  2. Appmus“Syncthing vs Onionshare Comparison (2026) | Feature by Feature”. https://appmus.com/vs/syncthing-vs-onionshare
  3. Appmus“FilePizza vs Onionshare Comparison (2026) | Feature by Feature”. https://appmus.com/vs/filepizza-vs-onionshare
  4. AlternativeTo“Apps with ‘Temporary File Hosting’ feature”. https://alternativeto.net/feature/temporary-file-hosting/

Primary sources: