Secret Sharing Tool Alternatives Compared
Server-side vs client-side encryption. What each tool offers and where the trust boundary falls.
The question behind every alternative search
You paste a password into a secret-sharing tool, hit create, and send the link. The recipient opens it and reads the password. The note self-destructs.
But what happened to your password between those two steps? With most tools, it went to the server as plain text over HTTPS. The server encrypted it for storage. When the recipient opened the link, the server decrypted the password and sent it back. The server had your password in readable form for the entire round trip.
That's server-side encryption. It protects data from outsiders, but not from the server itself.
Client-side encryption
The alternative is to encrypt before the secret leaves your browser. Your browser generates a key, encrypts the secret, and sends only the ciphertext to the server. The key goes into the URL fragment, the part after the #, which browsers never include in server requests.
The server stores encrypted data it can't decrypt. It handles storage and deletion, but the plaintext never passes through it.
Privnote
Server-side encryption with an undisclosed algorithm. Closed-source code. Text only, 1-view limit, ad-supported. Has a documented phishing clone problem.
OneTimeSecret
Server-side AES-256 encryption. Open source and self-hostable. Text only, 1-view limit. 100 KB anonymous sharing, 7-day expiry. Client-side encryption has been requested but is not on the roadmap.
Password Pusher
Server-side AES-256-GCM encryption. Open source, self-hostable. The most feature-rich server-side option: view limits up to 100, expiry up to 90 days, audit logging, API. File sharing from $19/month.
How Secret.Broker is different
Your browser encrypts the secret with XChaCha20-Poly1305 before anything goes to the server. The encryption key is in the URL fragment. The ciphertext goes to the server. I don't have the key to read it.
Files up to 20 MB are compressed and encrypted with the same cipher. One-time links with view limits from 1 to 25. Expiry from 15 minutes to 30 days. No account, no ads. Paranoid mode splits the link and decryption key for two-channel delivery.
The protocol page documents the full encryption stack. The encryption comparison explains why client-side encryption matters.
What to check before choosing
- Where the encryption happens. If the server handles your secret in plain text, the server is a single point of compromise.
- Whether the code is auditable. Closed-source tools ask you to trust their encryption claims without any way to verify them.
- File support. If you need to share .env files, SSH keys, or certificates, a text-only tool means pasting contents and hoping the formatting holds.
- Ads and tracking. Ad-supported tools run third-party scripts on the same page where you paste your secret.
Common questions
Is Privnote safe to use?
Privnote uses server-side encryption with an undisclosed algorithm. The code is closed-source, so the encryption claims can't be independently verified. HTTPS protects data in transit, but the server processes your secret in plain text. For casual notes it's functional. For passwords or API keys, a tool with client-side encryption means the server never handles your secret in readable form.
What does "zero-knowledge" mean for a secret-sharing tool?
The server stores your secret in encrypted form and doesn't have the key to decrypt it. Your browser encrypts before upload and the recipient's browser decrypts after download. The server can store, serve, and delete the ciphertext, but it can't read it.
Can I use Secret.Broker instead of Privnote or OneTimeSecret?
There's nothing to migrate. These tools don't store persistent data. Start using Secret.Broker for your next secret. Go to the tool, paste your secret, and send the link. See the password sharing or self-destructing messages pages for step-by-step walkthroughs.