Limitations
Explicit limitations to set accurate expectations:
- No password recovery. Zero-knowledge means no backup.
- No semantic validation of outputs.
- No guarantee of external system compatibility.
- No protection against local device threats.
- Not a replacement for production crypto libraries.
- No legal or compliance advice.
- No protection against all attack vectors.
What These Tools Actually Do
| Feature | Supported |
|---|---|
| Client-side encryption | ✓ Yes |
| Browser-based hashing | ✓ Yes |
| Local password generation | ✓ Yes |
| Zero data transmission | ✓ Yes |
| Server-side processing | ✗ No |
| Data recovery | ✗ No |
Limitations FAQ
If I lose an encrypted file, can you recover it?
No, and that is the design rather than a gap in it. The key never leaves your device and is never sent to us, so there is no copy we could use to decrypt anything. This is what makes the tools safe to use with real secrets, and it is also why a lost passphrase means lost data. Store the passphrase separately from the file, or keep a copy of the plaintext somewhere you control.
Are these tools a replacement for a production cryptography library?
No. They implement the standard algorithms through the browser's Web Crypto API, which is why they can run with no server and no installation. A production system still needs key rotation, access control, audit logging, algorithm agility and a reviewed key management process. Use these tools to handle a secret on one machine at one moment, not as the core of a multi-user system.
Does client-side encryption protect me from malware or a compromised device?
No. Moving computation into the browser changes who can read the data during processing, not who controls the machine. A keylogger, a compromised browser extension with host permissions, or an attacker who already has code execution in your session can observe the plaintext before encryption or the result after decryption. These tools reduce exposure to servers and third parties; they do not reduce risk on a device you do not control.
Will the output always be accepted by other systems?
It will match the specification, but downstream acceptance is not guaranteed. Our encoders produce standards-compliant output: AES-256-GCM per NIST SP 800-38D, Base64URL per RFC 4648, JWT decoding per RFC 7519. If a receiving system expects a particular padding, key size, line ending or encoding variant, that mismatch is a configuration question on their side, and no browser tool can detect it for you.
Do you offer legal or compliance advice?
No. Our compliance pages summarize how the architecture behaves in technical terms, such as what our tools process and what they never receive. Whether a given workflow satisfies a regulation is a legal question that depends on your organization, your sector and your jurisdiction. Treat these pages as engineering input for that conversation, and involve qualified counsel before relying on them.