Security

Will.com Plus uses zero-knowledge encryption. Your questionnaire answers and generated PDFs are encrypted in your browser before any of them reach our servers, using a key derived from a passphrase you choose. The unwrapped key never leaves your device. We have designed our system so that we cannot read your will, and the architecture below is what makes that claim verifiable rather than just asserted.

The free tier never sends your data to our servers in the first place. That has not changed.

When you set up Plus, your browser does the following:

1. Generates a 256-bit Data Encryption Key (DEK) using your browser’s cryptographic random number generator. This is the key that encrypts all of your content.
2. Derives a Key Encryption Key (KEK) from the passphrase you choose, using Argon2id (memory-hard, OWASP-recommended for password storage) with a per-user random salt.
3. Wraps the DEK with the KEK using AES-256-GCM. Only the wrapped form, the salt, and the iteration count leave your browser.

Every save of your questionnaire, every generated PDF, and every saved letter of instruction is encrypted with this DEK before upload, using fresh random IVs and AES-GCM authenticated encryption. Each ciphertext is also bound to its table, your account, and a version tag, so an attacker who could overwrite our database cannot swap your records into someone else’s account or replay an old version of your plan. The server receives opaque ciphertext.

When you sign in on a new device, you enter your passphrase, your browser re-derives the KEK, unwraps the DEK, and you can read your own data again.

All of this depends on the JavaScript we deliver to your browser being honest. Encryption that runs in code we control is only as trustworthy as that code; the limits of that assumption are spelled out in what this does not protect against.

• A breach of our database. An attacker who exfiltrates our Postgres tables sees only ciphertext.
• A breach of our file storage. The PDF blobs in our storage bucket are also ciphertext.
• Insider access at Will.com. Our staff cannot read your plan because the only key that can decrypt it lives in your browser and is derived from your passphrase.
• Backups. Database and storage backups carry the same ciphertext and are useless without your passphrase.

Zero-knowledge applies to the contents of your plan. Some metadata stays plaintext so the product can function:

• Your Clerk user ID, an opaque identifier that ties your billing and your encrypted vault to one account. We do not store your email address ourselves; that lives with Clerk (our authentication provider). We can send you mail for billing problems or annual reminders by addressing it through Clerk; we never copy your address into our database.
• Whether you have opted into annual reminder emails. A single boolean. The reminder copy itself is generic ("time to review your estate plan") and never references your data.
• That a document of a given type exists. The vault stores doc-type slugs ("will", "trust", "poa") so we can show you a list. The slugs are generic and intentionally do not encode your state of residence. The user-visible filename lives inside the encrypted envelope.
• Storage metadata. Each encrypted blob has a creation timestamp and a byte-size. We use these to render "generated 3 hours ago" labels and for storage accounting. The bytes themselves are ciphertext.
• Subscription status and dates, via Stripe. We see whether your subscription is active and when it renews. Stripe holds your card and billing name; we do not.

That is the full list of what a database inspector at Will.com could derive about you. It excludes your name, your address, your beneficiaries, your asset values, your healthcare wishes, your funeral preferences, and the rest of your plan content.

We cannot recover your data. There is no password reset that restores your stored answers. This is the cost of the guarantee that we cannot read your data either.

In that case, you can start the questionnaire over with a new passphrase. It takes about twenty minutes. Choose a passphrase you will remember, and consider storing it in a password manager.

The primitives:

• KDF: Argon2id (memory-hard) with hardcoded parameters per protocol version: m = 47 MiB, t = 1, p = 1, output = 32 bytes, per-user 16-byte random salt. Delivered via WASM since Web Crypto does not implement Argon2id natively.
• Symmetric cipher: AES-256-GCM with random 12-byte IVs per encryption.
• AAD binding: every ciphertext is bound to its table and version (for example, “plus_intake_drafts:v1”) so an attacker with database write access cannot swap rows between tables or contexts.
• Key wrap: AES-256-GCM with the KEK. The DEK never persists outside its wrapped form.

If you have a security question or want to report a vulnerability, email security@will.com.

For the broader privacy story, see our privacy policy.