Encrypt anything.
One ciphertext. Two control files. Two completely different truths. Runs entirely in your browser.
The thing you need to stay secret when the bytes leak. An API key or credential, a seed phrase, a private message, 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.
Wrong passwords return deterministic plausible fakes instead of random output. Structured secret types only. Learn how it works.
🔒 Generated in your browser. Only the secret type (e.g. "stripe-live-key") is sent to shape the sample, never your actual secret or ciphertext.
Two passwords. Argon2id 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.
Want to do this from your code?
Get a free API key. Same primitive, no browser. 500 calls/month, no card required.
Get a free API key →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.
If you downloaded a honey-mode.json with this record, add it so a wrong password returns a plausible fake. Leave empty for classic records.
Drop honey-mode.json here or browse
✓ 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 Argon2id. Standard, well-studied primitives. The deniability comes from how they are composed with control data. The primitives are battle-tested; the composition is the novel part (patent pending), open source, and pending an independent cryptographic audit.
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.
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 ✨ Generate a random decoy button above picks a shape-correct decoy across 69 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.
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 when the open beta opens?
deny.sh is in pre-beta. Our open beta opens Sat 4 July 2026, 08:00 BST with full SDKs and an MCP server for AI agents. One short note that day. No marketing after.