Secure Secret Sharing FAQ

Yes. Your browser encrypts the secret with XChaCha20-Poly1305 before it goes anywhere. The server never sees the plain text or the key. See the agreement for how it works, or the fragment security page for why the key never reaches the server.

You choose the view limit when you create it. Each open uses one. When views hit zero, the secret gets deleted.

You set a time limit. If it runs out before the views are used, the secret gets deleted.

A one-time link is a URL that can only be opened once. After the first person reads it, the encrypted data is deleted and the link stops working. Set the view limit to 1 when you create the secret. If you need more than one person to read it, raise the view limit. See the self-destructing messages page for a full walkthrough.

I can't recover it. The decryption key was part of the link, and I never had it.

Send it through whatever channel you'd normally use. If the secret is sensitive enough, send the link and the context about what it's for in separate messages or channels.

No. The link contains the decryption key. If I send it, I've seen it. That defeats the point.

No. No accounts, no signup.

No. The secret is encrypted before it gets to me. I can't read it, so there's nothing to log.

XChaCha20-Poly1305 for the secret itself. TLS in transit and AES-256 at rest. The protocol page has the full breakdown.

Yes. Paste the key, set a view limit of 1, and send the link. The recipient opens it once, copies the key, and it's gone. No more API keys sitting in Slack threads or email chains.

Yes. Attach the .env file when you create the secret. Your browser zips and encrypts it with the same XChaCha20-Poly1305 used for text. The recipient downloads and decrypts it in their browser. Maximum file size is 20 MB.

Normal mode puts the decryption key in the link itself. Paranoid mode gives you the link and the key separately. Send the link over email and the key over Signal (or any second channel). Anyone intercepting only one channel gets nothing usable.

An attacker would get ciphertext and no keys. The decryption keys are in the URL fragments, which never reach the server. The ciphertext is also bound to the secret.broker domain, so it can't be decrypted on a different site. Secrets that have already expired or been viewed are hard-deleted and not recoverable at all.

Yes. Set the view limit to match the number of people who need it. Each person opens the link, copies the password, and the view count decreases. When it hits zero, the password is deleted. For long-term shared passwords, use a password manager. This is for the one-time send.

Create the secret with a view limit of 1 and a short expiry (an hour or a day). Send them the link. Once they've opened it and saved the credentials on their end, the secret is gone. Nothing persists in chat logs or email archives for someone to find later.

They can see that you visited secret.broker. They cannot see the secret itself, because your browser encrypts it before it leaves your machine and the decryption key stays in the URL fragment, which isn't sent over the network. A corporate proxy or firewall sees the same encrypted payload the server sees.

Yes. The site is responsive and the encryption runs entirely in your mobile browser. No app to install.

Up to 20 MB. Files are compressed and encrypted in your browser before upload. Small secrets (under 32 KB of ciphertext) are stored inline. Larger payloads go to object storage via a pre-signed URL, so the server never handles the ciphertext directly.

Not currently. The encryption runs in your browser, so you can inspect the client-side code in your browser's developer tools to verify what it does. The protocol page documents the full encryption stack.

A password manager stores passwords long-term. This gets them from one person to another. When you need to hand someone a credential without it sitting in a chat log, that's what this is for. Use both: the password manager for storage, this for the handoff.

Use a tool with client-side encryption. Your browser encrypts the password before it leaves your machine, so the server never sees it in readable form. Paste the password, set a view limit of 1, and send the link. The password is deleted after it's read.

Go to the tool, paste the password, set the view limit and expiry, and send the link. Your browser encrypts it with XChaCha20-Poly1305 before anything reaches the server. See sharing passwords for the full walkthrough.

Create a self-destructing link. Paste the password, set it to 1 view, and send the link. The recipient opens it, copies the password, and the link goes dead. No account, no software to install. For ongoing storage, a password manager is still the right tool.

A message that deletes itself after being read. Set the view limit to 1 and the message is destroyed the moment someone opens the link. If a second person tries the link, there's nothing there. See self-destructing messages.

No. Google Docs are searchable, shareable, and backed up. Access permissions drift over time. A password in a shared document is accessible to everyone who can open that document, plus anyone they share it with. Use a self-destructing link instead.

Create a separate secret for each credential with a 1-view limit and a 24-hour expiry. Send the links over Slack or email. The developer opens each link, saves the credential, and the encrypted data is deleted. See onboarding credentials.

Secrets management tools like HashiCorp Vault store credentials long-term, rotate them, and inject them into deployments. Secret sharing handles the one-time handoff: getting a credential from one person to another without leaving a copy in the channel. Use both. The vault stores it. This sends it.

Yes. Send details to security@secret.broker.