A lot of tools claim to store your data "encrypted locally," but the phrase gets used loosely. Sometimes it means genuine end-to-end encryption where only you hold the key. Sometimes it means the data is base64-encoded (which is not encryption at all — it's just a different text representation, trivially reversible). Understanding the actual mechanics is the only way to know which one you're getting.
The two building blocks that make it real encryption
Two specific technologies, used together, are what separate genuine client-side encryption from a superficial claim:
- PBKDF2 (Password-Based Key Derivation Function 2) — turns a human-memorable passphrase into a cryptographic key. Critically, it does this slowly and deliberately, running the underlying hash function tens or hundreds of thousands of times, specifically to make brute-force guessing expensive. A modern baseline is around 210,000 iterations with SHA-256 — enough to meaningfully slow down an attacker without being noticeable to a legitimate user typing their passphrase once per session.
- AES-GCM — the actual encryption cipher. GCM (Galois/Counter Mode) is an "authenticated" encryption mode, meaning it doesn't just scramble your data — it also generates a cryptographic tag that detects tampering. If even one byte of the encrypted data is altered or corrupted, decryption fails loudly with an error rather than silently returning garbage or, worse, subtly wrong data.
What "only ciphertext touches storage" actually means
In a properly implemented client-side vault, three things never leave memory and are never written to disk or localStorage: your raw passphrase, the derived encryption key, and the plaintext content of your notes. What does get persisted is exactly three pieces of data, all of them meaningless without the passphrase: a random salt (used to derive the key), a random initialization vector (used by AES-GCM), and the ciphertext itself. If someone got full read access to your browser's localStorage, all they'd find is opaque encrypted bytes — no note titles, no note bodies, nothing legible.
Why the passphrase has to be re-entered every session
This is a deliberate design choice, not a missing "remember me" feature. If the derived key were cached anywhere persistent, an attacker with access to that storage could decrypt everything without ever knowing your passphrase — which defeats the entire point. Requiring the passphrase fresh each session, deriving the key only in memory, and discarding it on "Lock Vault" or when the tab closes is what keeps the encryption meaningful rather than cosmetic.
How to verify a wrong passphrase fails safely
A subtle but important property: what happens if you (or an attacker) enters the wrong passphrase? A well-implemented system doesn't silently return corrupted garbage that looks like it might be your data — it fails cleanly and immediately, because AES-GCM's authentication tag won't validate against a key derived from the wrong passphrase. The correct user experience is a clear "incorrect passphrase" message, not a crash, not a blank screen, and definitely not a plausible-looking but wrong result.
What encrypted export/import should and shouldn't do
A backup or export feature is only as safe as the vault itself if it exports the same ciphertext-plus-salt-plus-IV bundle rather than decrypting first. A backup file that contains your notes in plaintext defeats the purpose the moment you email it to yourself or drop it in cloud storage. The correct behavior is: the exported file is exactly as encrypted as the live vault, and importing it on another device still requires the original passphrase to unlock.
A quick checklist for evaluating any "locally encrypted" tool
- Does it use a real key-derivation function (PBKDF2, Argon2, scrypt) with a meaningful iteration count, rather than using your passphrase directly as a key?
- Does it use an authenticated cipher (AES-GCM, ChaCha20-Poly1305) rather than an unauthenticated mode that can be silently corrupted?
- Does entering the wrong passphrase fail cleanly with a clear error, rather than producing garbled-but-plausible output?
- Is the exported backup file itself still encrypted, or does it leak plaintext the moment it leaves the app?
Encrypted Note Vault was built and tested against exactly this checklist: PBKDF2 with 210,000 iterations, AES-GCM 256-bit encryption, a verified round trip confirming correct passphrases decrypt cleanly and wrong passphrases fail with a clear error rather than corruption, and export files that remain fully encrypted outside the app.
Frequently Asked Questions
Yes — Encrypted Note Vault encrypts every note with AES-GCM using a key derived from your own passphrase via PBKDF2, and only ciphertext ever touches localStorage. It's a one-time $6.99 purchase — no subscription, no account required.
Decryption fails cleanly with a clear "incorrect passphrase" message. AES-GCM's built-in authentication check rejects a key derived from the wrong passphrase, so you never get silently corrupted or garbled data — just an honest error.
Nowhere. The passphrase is only used in memory to derive the encryption key for your current session and is never written to localStorage, a cookie, or sent anywhere. That also means if you forget it, the notes genuinely cannot be recovered — that's the security trade-off by design.
Yes, use Export Encrypted Backup to download a JSON file containing your still-encrypted vault (salt, IV and ciphertext, no plaintext), then use Import on the new browser and unlock it with the same passphrase.
The full encrypt/decrypt round trip was tested directly against the Web Crypto API: sample notes were encrypted, serialized in the same format used for localStorage, and decrypted back to confirm identical plaintext, while both a wrong passphrase and a tampered ciphertext byte were confirmed to fail decryption cleanly rather than corrupting data.