Private secret sharing

Send passwords securely, end-to-end encrypted

Paste a password or any sensitive text. Secret Sharing encrypts it in your browser and gives you a one-time link and a separate decryption passphrase. The server never sees your plaintext or your passphrase - not now, not ever.

No accountNo trackingOne-time viewBrowser-side AES-GCM

Create a one-time secret or create a link-only secret →

Encryption happens entirely in your browser. The decryption passphrase never leaves this page. How it works →

Encryption happens entirely in your browser. Nothing in this box is sent as plaintext.

The secret is permanently deleted the first time it's viewed, or at expiry - whichever comes first.

WebF1 Tip: Use the shortest expiration time that is practical - the less time a secret sits on a server, the smaller the window for compromise.

How to send a secret securely

  1. 1

    Paste your secret

    Your browser generates a 256-bit AES-GCM key locally and encrypts the text in-memory. The plaintext never leaves your device.

  2. 2

    Get a link and a passphrase

    We store only the encrypted ciphertext and a random IV. You receive a shareable link (containing the payload ID) and a separate four-word decryption passphrase.

  3. 3

    Send over two channels

    Send the link through one channel (email, chat) and the passphrase through a different one (SMS, phone call, in person). An attacker who compromises one channel still cannot read the secret.

  4. 4

    One-time view, then gone

    When the recipient opens the link, the server returns the ciphertext and then immediately deletes the record. The recipient enters the passphrase in their browser and decrypts locally - the secret is permanently destroyed.

Why two-channel delivery matters

A single channel - your email, your Slack, your SMS - can be compromised. By splitting the secret into a link and a passphrase, and sending each through a different medium, you raise the cost of compromise dramatically. This is the same principle that protects two-factor authentication.

Why a passphrase, not a string of random characters?

Older tools hand you a decryption key that looks like kQ9$nL2#vX7&pR. It’s strong, but it’s also painful to read aloud, easy to mistype, and visually screams “I am a password.” Anyone glancing at the recipient’s screen or chat history knows instantly what they’re looking at.

Secret Sharing instead gives you four random English words - for example staple-orbit-canvas-river - drawn from a 7,776-word list (the EFF diceware wordlist). Four words means roughly 3.6 quadrillion possible combinations (77764), and each guess has to run through an Argon2id memory-hard derivation (64 MiB of memory, 3 passes) before it can even be tested - so an offline attacker cannot simply throw GPUs at it the way they can with PBKDF2 or bcrypt. Compared to a short random-password string, that is:

  • Readable. A recipient can read “staple orbit canvas river” once and remember it long enough to type it.
  • Dictatable. You can read it over the phone without spelling out letters or distinguishing 1 from l from I.
  • Incognito. Four plain words in a chat look like a note, not a credential. They don’t trigger the “this is a password” reflex in screenshots, screen shares, or shoulder-surfers.
  • Harder to mistype. Whole words have fewer ambiguous characters than symbols; a typo usually produces nonsense rather than a near-miss the browser quietly rejects.

The full AES-256 key is derived from your passphrase with Argon2id - the OWASP-recommended memory-hard password hash - using 64 MiB of memory, 3 iterations, 4 parallel lanes, and a per-secret random salt. Password strength checkers such as Bitwarden’s typically rate a four-word diceware passphrase at centuries to crack offline, and Argon2id’s memory cost makes it far more expensive to parallelize on GPUs and ASICs than PBKDF2 or bcrypt.

Frequently asked questions

Can the server read my secret?

No. Only the ciphertext (the encrypted bytes), an IV (the “initialization vector” - a random one-time value that makes each encryption unique even for the same plaintext), and a non-secret salt are stored. The AES-256 key is derived in your browser from your passphrase and never sent to the server, written to the database, or logged.

What happens after the secret is read?

It is deleted atomically the instant it's fetched, using DELETE … RETURNING. Even two simultaneous readers cannot both receive the payload.

What if it's never read?

A background job hard-deletes every expired record every 15 minutes. You can also choose a short expiry (down to 15 minutes) for extra caution.

Do you track me?

No. There are no third-party analytics, no advertising scripts, and a strict no-referrer policy. No accounts are required.

Built by WebF1, LLC

Secret Sharing is a free privacy-first tool from WebF1, LLC, a web software company focused on practical, secure, no-nonsense web products.