OnionShare

OnionShare is the canonical ephemeral self-hosted file transfer + chat + microsite tool — a desktop application that spins up a Tor `.onion` service on your own machine for one-shot transfers, where the recipient connects via Tor Browser. Listed at Grade A · editor's pick because OnionShare occupies a structural category-of-one: no third-party hosting, no operator infrastructure, no expiration that depends on someone else's policy. Mandatory tool in the privacy stack for sending files larger than email allows, hosting a temporary file drop, or running a short-lived microsite that disappears when you close the lid.

Background. OnionShare was created by Micah Lee (security technologist, formerly of The Intercept) in 2014 and has been maintained as an open-source project since. Released under the GPLv3 license; codebase at github.com/onionshare/onionshare. The application is cross-platform desktop (macOS, Windows, Linux) plus a Linux-only CLI variant for headless operation. Bundled in Tails OS as a default tool — when you boot Tails, OnionShare is installed and ready, no separate setup. The Tor Project doesn't develop OnionShare but cooperates with the maintainers; OnionShare uses the same Tor library and `.onion` v3 service infrastructure as Tor Browser. Funding: grants from Open Tech Fund and Freedom of the Press Foundation (Lee's organisational context), plus contributor labour. The codebase has received independent security audits with reports linked from onionshare.org.

What you trust. Your local machine — OnionShare runs entirely on your computer; the `.onion` service is hosted on your device, the files don't leave your disk until the recipient downloads them. Tor network — both you and the recipient connect via Tor; the files are encrypted in transit via the Tor protocol; no exit relay is involved (onion services are end-to-end Tor-routed). `.onion` v3 cryptography — the address is derived from a public key; only someone with the address can find the service. Ephemeral by default — when you close OnionShare or click stop, the service disappears; no persistent state on third-party infrastructure. Optional authentication — OnionShare supports adding a secret URL slug (private mode) so even leaking the `.onion` address doesn't grant access without the slug. Open-source codebase + audited — the source is auditable; signed releases are reproducible from source; the codebase has been independently audited. No operator infrastructure — there is no OnionShare company that could be subpoenaed, no central service that could be compromised, no analytics SDK that could leak metadata.

Operational specs. Platforms: macOS, Windows, Linux desktop apps (PyQt-based); Linux CLI for headless operation; bundled in Tails OS. Modes: Share Files (one-shot transfer; recipient connects, downloads, service closes), Receive Files (you host an upload form; senders submit files anonymously into your machine), Host a Website (static HTML/CSS/JS site served from your machine over `.onion`), Chat (anonymous chat room hosted on your machine). Onion service: `.onion` v3 (the modern format with strong cryptography); the address is a 56-character base32 string. Authentication options: public (anyone with the address can connect), private (address + secret URL slug required), client-authorization (advanced: only specific Tor clients with pre-shared keys can connect). File size: limited only by your disk space and your patience — Tor onion transfer speeds are typically 100KB/s to a few MB/s depending on relay paths. Expiration: configurable per-share — auto-stop after N downloads, auto-stop after a timer, or manual stop. Tor integration: OnionShare bundles its own Tor instance OR can use a system Tor; for users running a local Tor (e.g., Tails users, Whonix users), the system-Tor mode is preferred.

Philosophy. OnionShare's editorial differentiator is the ephemeral-self-hosted-service model. Cloud file-share services (Google Drive, Dropbox, WeTransfer, Send.tres) involve a third-party operator who sees who-sent-what-to-whom and retains the file on their servers; this is a leak even when content is encrypted at rest. End-to-end encrypted services (Bitwarden Send, Send.tres, Magic Wormhole) reduce the content-leak but still involve a service operator who sees connection metadata. OnionShare goes further: there is no operator at all, the service is your machine, and when you close it the service vanishes. The trade-off: your machine has to be online and reachable during the transfer; if you close your laptop mid-transfer, the file doesn't continue from a cloud relay because there is no cloud relay. For one-shot transfers where you control the timing, this is the cleanest possible trust model.

Grade rationale. Grade A and editor's pick reflect: open-source GPLv3 codebase; created by a named security technologist (Micah Lee) with a public track record in privacy tooling; bundled in Tails OS as a default tool (the canonical signal that the Tails community trusts it); independent security audits with public reports; cross-platform desktop (macOS, Windows, Linux) + CLI for headless ops; first-class `.onion` v3 support; multiple operating modes (file send, file receive, website host, chat) all over Tor onion services; optional secret-slug authentication; ephemeral by design (no persistent third-party state); over a decade of operational continuity (since 2014); maintained official Tor onion at lldan5gahapx5k7iafb3s4ikijc4ni7gx5iywdflkba5y2ezyg6sjgyd.onion. Last verified 2026-05-13.

Useful when. You need to send a file larger than email allows to a specific person — share the `.onion` address through a separate secure channel (Signal, PGP-signed message, in-person QR), they download via Tor Browser, the service closes when done. You need to receive files anonymously — open OnionShare's Receive mode and share the address; senders submit files into your machine without revealing their identity to a third-party operator. You're a journalist receiving documents from sources — OnionShare's Receive mode is built for this use case and is recommended by SecureDrop and Freedom of the Press Foundation. You need to host a temporary microsite for a specific audience — drag in HTML files and OnionShare serves them from your machine over `.onion`. You're on Tails and need a file-sharing tool that doesn't break Tails' privacy posture — OnionShare is the canonical pick. You want zero third-party operator in the file-transfer trust path.

Caveats. Your machine must be online during transfer — if you close OnionShare or shut your laptop mid-transfer, the recipient can't continue from a cloud relay (because there is no cloud relay). Plan accordingly: keep the laptop open until confirmed downloaded, or use the auto-stop-after-N-downloads option to know when it's done. Tor transfer speeds are slow — 100KB/s to a few MB/s typical; a 10GB file transfer takes hours. For large transfers, schedule appropriately. Recipient needs Tor Browser (or a Tor-capable client) — non-technical recipients may need help installing Tor Browser to connect. Onion-v3 address is 56 chars long — sharing the address via a side channel (Signal, etc.) means transmitting a long string; consider QR codes for in-person sharing. No built-in chat history — OnionShare's chat mode is ephemeral by design; messages disappear when the service closes. For persistent group communication, use SimpleX, Matrix, or Cwtch. CLI mode is Linux-only — for headless server hosting (e.g., a long-running file drop), you need a Linux machine; the macOS/Windows desktop apps are GUI-only. Custom-domain hosting isn't supported — OnionShare uses generated `.onion` addresses; for vanity-prefix `.onion` addresses or DNS-mapped sites, you need a separate Tor onion service workflow (not OnionShare's domain). File-receive mode is a deliberate attack surface — when you open Receive mode, anyone with the address can submit files into your machine; pair with private-mode authentication for high-trust scenarios, and treat received files as untrusted (sandbox / virus-scan before opening). Single-user model — OnionShare is one-user-one-service; for organisational use cases with multiple senders/receivers, see SecureDrop instead.