How this works

SendPass is built so that even whoever runs this server cannot read the secrets that pass through it. Here's exactly what that means and why.

✓ This connection is encrypted (HTTPS)

The link is the key

When you create a secret, the server generates a long random token and uses it to encrypt your text. That same token becomes part of your one-time link. The server only ever stores the encrypted secret and a one-way hash of the token, used to look up the right row — never the token itself, and never anything the encryption key could be reconstructed from. Anyone with access to the database, including us, sees only ciphertext. Without the link, it's unreadable.

An optional password adds a second lock

If you set a password when creating the link, it's mixed into the same key derivation as the token — decrypting then requires both the link and the password. The password is never stored, in any form. A wrong password doesn't produce an error message pulled from a database; it produces the wrong decryption key, which fails on its own. Send the password to your recipient through a different channel than the link (a text message, a phone call — not the same email or chat as the link itself).

Read once, then gone

The first successful decryption permanently deletes the secret from the database, in the same step that reveals it — there's no window where it exists both read and retrievable. If it's never opened, it's deleted automatically once its expiry passes (checked every 5 minutes). A wrong password does not delete anything, so a mistyped password can be retried.

Guessing is rate-limited

Attempts to open a link are capped per IP address, so trying to brute-force a token or password is impractical long before it becomes a serious threat — the token alone is a 256-bit random value, far beyond what rate-limited guessing could ever reach.

Nothing sensitive is logged

This application does not log tokens or secret content, anywhere, under any circumstances. An invalid, expired, or already-used link produces the same generic message as a wrong password — the response never reveals which one it actually was.

Sending the link by e-mail

Once your link is ready you can have this server e-mail it to the recipient. To do that you need to sign in — creating and opening secrets never requires it. Without sign-in, anyone could make this server send mail to any address, turning it into a spam relay. Signing in ties every e-mail to a known sender: the recipient sees who sent it, and replies go to that person, not to the server. Each account can send at most 20 e-mails per 24 hours.

The server only ever mails a link it builds itself, for a secret that is still unread, so nobody can use it to send arbitrary text. The password, if you set one, is never included — and remember that a link sent by e-mail passes through the mail servers in between, so send the password some other way.

How sign-in works

There are no passwords to remember. Enter your e-mail address and you'll get a one-time sign-in link, valid for 30 minutes. Click it in the same browser and you're signed in. Open it on another device or in another browser instead, and it shows a 6-digit code to type into the browser where you started — so a link that is opened by someone else, or by a mail scanner, can't sign anyone in on its own.

Signing in sets a cookie that keeps you signed in on this device for a year, or until you sign out. The server stores only a hash of that cookie and your e-mail address — never the cookie itself — and your secrets are not linked to your account in any way. (While a sign-in link is pending, a second, short-lived cookie remembers which browser asked for it; it's removed once you're signed in.)

No tracking

No analytics, no tracking scripts, and no cookies beyond the sign-in cookie above, which is only set if you sign in. Besides sign-in sessions, the only thing stored is the encrypted secret itself, until it's read or it expires.