Encrypt anything.
One ciphertext. Two control files. Two completely different truths. Runs entirely in your browser.
The thing you actually need to keep private. A seed phrase, a message, a password, a confession, a file. Everything is encrypted in your browser; nothing is sent to any server.
The plausible alternative. When the bytes leak, this is what an attacker recovers. Make it boring, make it believable, and write something an attacker would accept as the real message and stop looking.
Two passwords. scrypt derives the encryption key from both. You need both to decrypt. Neither is stored anywhere, ever.
Both passwords are needed together. Neither is stored anywhere.
🔒 Everything runs in your browser. Nothing is sent to any server.
✓ Encrypted successfully
One ciphertext. Two control files. Two different truths.
How to use these files: Store the ciphertext anywhere safe. Keep the real control file somewhere only you can access. Put the decoy control file somewhere plausible, like a notes app or a drawer. When the bytes leak (cloud breach, lost device, compromised agent), the attacker recovers the decoy. Your real data stays separated.
Keep this safe. With this + your passwords, you get the real message back.
Give this to anyone demanding access. Same ciphertext, different truth.
The encrypted hex you stored or were given. Either paste it directly or upload the .enc file.
A control file is what decides which truth you get back. Use the real control file to recover your real message. Use the decoy control file to recover the decoy.
Both passwords are required to decrypt, exactly as when you encrypted.
✓ Decrypted successfully
Here is what that ciphertext + control file + passwords combination reveals.
Done? Copy what you needed and close this tab. Your decrypted content was never sent to a server, but it is on your screen now.
Zero knowledge. Zero trust required.
This page runs entirely in your browser. Your message, your decoy, your passwords never leave your device. There is no server call. Don't take our word for it:
The encryption uses AES-256-CTR with keys derived via scrypt. Standard, well-studied primitives. No novel cryptography. The deniability comes from XOR composition with control data, not from anything clever or untested.
deny.sh is open source: the SDK is Apache 2.0, the application layer is AGPL-3.0. You can read every line. You can run the 22-test verification suite yourself. Don't trust us. Verify.
Need to store your control files securely? Use the encrypted vault. Want to hide your backup inside a photo? Steganography. Split it between trusted people? Shamir's Secret Sharing. Set up a dead man's switch? That too.
For the full technical specification, read the whitepaper.
Best practices.
Deniable encryption is one layer. To get the most out of it:
Make your decoys believable. An empty string or "test123" won't fool anyone. Use something that matches the kind of data you'd plausibly have. Old passwords, dummy seed phrases with small balances, mundane notes. The Live engine toggle above can also generate shape-correct decoys across 17 credential types if you'd rather not write your own.
Use strong, unique passwords. Deniability protects the bytes when they leak, not against weak passwords. Use 12+ characters, mix types, don't reuse them.
Store control files separately from the ciphertext. If someone finds both in the same folder, the deniability is intact but the operational security isn't. Use the vault, a hardware wallet, or a separate device.
Split sensitive control files. Use Shamir's Secret Sharing to split a control file across 3 of 5 trusted people. No single party can reconstruct it alone, including the holder of the ciphertext.
Consider steganography. If the existence of an encrypted file is itself suspicious, hide it inside a photo. The image looks identical to the original.
Set up a dead man's switch. If you can't access your data, someone you trust should be able to. Configure automatic release if you stop checking in.
Don't rely on a single tool. Combine deny.sh with hardware wallets, multisig, air-gapped machines, and good physical security. The best defence is layered.
Want a heads-up on launch day?
deny.sh is in pre-launch. We launch Sat 4 July 2026, 08:00 BST with full SDKs, an MCP server for AI agents, and a launch-week Lifetime Pro tier ($499 forever, capped at 200). One short note that day. No marketing after.