Encryption that never leaves your device.

Where the work happens

Every cryptographic operation on this site runs in your browser through the Web Crypto API, the same vetted engine your browser uses for HTTPS. Your passphrase, your keys, and your plaintext are handled entirely on your device. The server's only job is to serve these pages and — for one-time secrets — to hold a blob of ciphertext it has no way to read.

Passphrase encryption (Text & File)

When you lock something with a passphrase:

• A random 16-byte salt is generated, and your passphrase is stretched into a 256-bit key with PBKDF2-HMAC-SHA-256 at 250,000 iterations. Stretching makes guessing a weak passphrase expensive for an attacker.
• The data is encrypted with AES-256-GCM using a fresh random 12-byte nonce. GCM also produces an authentication tag, so any later tampering is detected rather than silently accepted.
• The output container is magic · salt · nonce · ciphertext. Text is base64url-armored behind a dlenc1: marker; files get a .dlenc extension. Everything needed to decrypt is inside the container — except the passphrase, which only you have.

Because the salt and nonce are random every time, encrypting the same text twice yields two completely different blocks. There is no decryption backdoor and no passphrase recovery: if you lose the passphrase, the data is gone.

One-time secrets

This is the only tool that talks to the server, and it's built so the server stays blind:

• Your browser generates a random 256-bit key and encrypts the secret with AES-256-GCM locally.
• Only the ciphertext is sent to the server, which files it under a random unguessable ID with your chosen expiry and read limit.
• The decryption key is placed in the link's URL fragment (the part after #). Browsers never transmit the fragment to a server, so the key reaches the recipient without ever reaching us.
• When the recipient opens the link and clicks to reveal, their browser fetches the ciphertext, decrypts it locally, and the server deletes the record once the read limit is reached.

A dump of our storage would reveal nothing but opaque bytes. The trade-off: anyone who has the full link can read the secret, so treat the link like the secret itself.

Key exchange (public keys)

The Keys tool uses ECDH on curve P-256. You publish a public key; a sender's browser generates a throwaway (ephemeral) keypair, performs an ECDH agreement with your public key to derive a one-off AES-256-GCM key, encrypts, and sends you the ciphertext plus the ephemeral public key. Only your private key can re-derive that AES key. This is the same ephemeral-static pattern used by tools like age.

What this protects — and what it doesn't

It protects: data sitting on someone else's server, files in a shared drive, a secret in transit through channels you don't control, a note you want read once. If the ciphertext leaks, it's useless without the key.

It does not protect against:

• A compromised device — malware or a keylogger sees your plaintext before it's ever encrypted. Encryption assumes your own machine is trustworthy.
• A weak passphrase — stretching buys time, not miracles. Use a long, unique passphrase; a manager-generated one is best.
• Someone you chose to share with — once they can decrypt, they can do anything with the contents.
• Anonymity — this hides content, not the fact that you connected. Pair it with the VPN if you need to obscure the connection itself.

Lawful use

Strong encryption is ordinary, legal, and protective — it's what keeps banking, messaging, and medical records safe. These tools exist to protect real people's privacy. They are not a shield for anything unlawful, and we'll cooperate with valid legal process to the (deliberately minimal) extent our design even allows.