Send: encrypted file sharing with links that expire, carried on by the community after the original was shut down
Summary
Drop a file in the browser, get a link that expires by time or by download count, and the key never leaves the link itself. No account, and the whole thing can be self-hosted.
Recommend- Name
- Send
- Version
- 3.0.16
- Open source
- Open source
- Operating system
- WindowsmacOSLinuxAndroidiOS
- Website
- https://send.vis.ee/
- Updated
- 2026-10-06 21:54
A share link that behaves like it used to
Some people still remember the shape of it: drag a file into a web page, get a link with a deadline, and whoever opens it downloads the file. Encrypted end to end, no account anywhere. The service that popularised that shape was shut down by its maker in 2020, but the code survived under an open licence, and a maintainer picked it up and kept it alive as a community project. What exists now is a public instance anyone can use plus the ability for anyone to run their own. As of September 2026 the project is still maintained, with the main repository on one code host and official mirrors on another.
The encryption happens in your browser
The difference from a cloud drive sits in who holds the key. The file is encrypted in the browser before anything is uploaded, and the key needed to decrypt it exists only in the fragment of the share link. The server holds ciphertext from beginning to end; neither the host nor the developer can see the contents. The recipient's browser does the decryption when the link is opened. Take the server's storage away wholesale and what comes with it is a heap of blocks nobody can read. That is the privacy floor this model rests on, and it is a real one rather than a promise in a policy document.
The link is the policy: time, count, password
The sender sets the rules. A link can expire after a period, or after a number of downloads, or both combined. Sensitive files can carry an access password on top, which the recipient types before decryption. Once the link expires or the count runs out, the encrypted data on the server is deleted automatically, leaving no long-lived file sitting there. No party registers an account anywhere in this. Open the page, drop the file, copy the link — three steps for a private transfer, which suits exactly the material nobody wants parked in the cloud for months: a contract draft, a scanned ID, a set of photos headed for one person.
Open source, self-hostable, your data your call
The project is open under the MPL licence, and a complete deployment is offered as container images, so an organisation with the appetite can stand it up on its own network or server: maximum file size, expiry policy and storage quota are all configurable, and no data passes a third party. For an ordinary user the public instance works as it is. For an organisation that cares about data sovereignty, a self-hosted instance combined with internal access rules can take the place of a commercial large-file transfer service. One caveat worth stating: the public instance is run by a maintainer with limited resources, so large files and heavy traffic belong on a self-hosted deployment.
The small ecosystem around it
The same author also maintains a command-line tool, ffsend, which uploads a file from a terminal and prints the share link — useful for scripted transfers and for handing a file from one server to another, using the same encryption and expiry mechanics as the web page. Two pieces of advice for use. First, the key to a share link lives inside the URL, so whoever holds the link holds the ability to decrypt; send it only to the intended recipient, and add an access password when it matters. Second, set expiry tighter rather than looser: a day or two usually covers the window in which the other side will download, and a file that disappears early is safer than one that lingers. Sending from a phone browser works too, which makes passing a photo to a colleague more direct than a messaging app's file transfer.