Secretshare

Encrypting in this browser

Send or Encrypt Secret
File or Text once.Then it's gone.

Secure 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

Destruction and access
Human confirmation is always required Slack, Discord and Teams generate link previews. Preview requests can inspect availability but cannot consume the encrypted payload.

Private by design  /  Built for handoffs

What is SecretShare?

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

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 work

File sharing

Encrypt files before upload

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.

Explore encrypted file sharing

Optional protection

Add a separate passphrase

Require a passphrase when the link alone should not be enough. Communicate that passphrase through a different channel.

Review the security model

What your teammate opens

One 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.

How SecretShare works

Encryption

The browser generates a 256-bit key and encrypts text or file bytes with authenticated AES-GCM before sending ciphertext.

The key

The link places the key after #. Browsers do not include URL fragments in HTTP requests, keeping the key separate from stored ciphertext.

Bot defense

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

Files up to 150 MB are read and encrypted locally. Their name, media type, and contents are all inside the encrypted payload.

Deletion

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 now

Common questions

Secure sharing, explained plainly.

What can I send with SecretShare?

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.

Can SecretShare read the content?

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.

What happens when the recipient opens the link?

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.

Is an account required?

No. The sender and recipient can use the core text and file-sharing flow without creating an account.