Password sharing
One link, one retrieval
Send credentials through a one-time link instead of placing reusable plaintext in email, Slack, Discord, or a ticket.
How one-time links workSecure password sharing and encrypted file sharing from your browser. Create a one-time link without an account; the recipient confirms before the encrypted payload is consumed.
Draft · no. 0000-0000
0 characters — encrypted locally before upload
Encrypted one-time link
The key lives after the #
The fragment contains the decryption key. Browsers do not send URL fragments in HTTP requests, so the server receives the secret ID but never this key.
Private by design / Built for handoffs
SecretShare is a no-account web application for secure password sharing and encrypted file sharing through one-time links. It encrypts passwords, API keys, environment variables, private notes, or one file up to 150 MB in the sender’s browser with AES-256-GCM. The server stores ciphertext, while the decryption key remains in the URL fragment.
Password sharing
Send credentials through a one-time link instead of placing reusable plaintext in email, Slack, Discord, or a ticket.
How one-time links workFile sharing
Share Word documents, Excel spreadsheets, PDFs, .env files, SSH keys, or any other file type up to 150 MB. The filename, media type, and bytes stay inside the encrypted payload.
Optional protection
Require a passphrase when the link alone should not be enough. Communicate that passphrase through a different channel.
Review the security modelOne page, one button, no account. A shared link opens this confirmation gate.
Secretshare
Open a generated link to receive an encrypted secret.
A bot preview can't press this.
Read it now — this page won't load again
Download encrypted fileWiped
This secret was opened, expired, or does not exist.
The browser generates a 256-bit key and encrypts text or file bytes with authenticated AES-GCM before sending ciphertext.
The link places the key after #. Browsers do not include URL fragments in HTTP requests, keeping the key separate from stored ciphertext.
A non-consuming landing request protects secrets from chat preview fetches. Only an explicit POST from the Open and destroy button consumes a secret.
Files up to 150 MB are read and encrypted locally. Their name, media type, and contents are all inside the encrypted payload.
The backend claims a stored record with an atomic rename before returning it, so concurrent opens cannot both retrieve the same ciphertext. Expired records cannot be consumed.
Stop pasting credentials into Slack.
Send one nowCommon questions
Password text, API keys, environment variables, recovery codes, private notes, or one file of any type up to 150 MB—including Word documents and Excel spreadsheets. Do not use the service as permanent storage.
The browser encrypts the content before upload, and the decryption key stays after the link's #. The server stores ciphertext and does not receive that fragment. As with any web encryption tool, users must still trust the JavaScript delivered by the site.
The first page checks availability without consuming the payload. After a person selects “Open and destroy,” the backend atomically claims the record, returns the ciphertext once, and deletes the stored record.
No. The sender and recipient can use the core text and file-sharing flow without creating an account.