How to Choose an Encryption Tool

Five facts you can verify decide whether an encryption tool deserves trust. Where the encryption runs, who controls the key, which standard and parameters are used, whether the threat model fits your data, and what the service stores after you close the tab. Marketing language tells you nothing about any of them. Here is the order that matters.

23 September 2026

Start With Where Encryption Happens

Watch the network tab

Encryption can run in your browser before data leaves the device, on the provider's server after upload, or in between. The location decides what the provider can ever see. If plaintext or a raw key crosses the network, the provider's staff, logs, and backups become part of your attack surface, regardless of intent.

Open the developer tools and watch the network tab while you encrypt a short test string. A client-side tool sends nothing while it encrypts. A server-side tool posts your text and returns ciphertext. That single observation is worth more than any feature list.

Try it: open the network tab, encrypt one string, watch it stay.

Note whether encryption happens before or after the upload
Check whether a page reload forces a fresh key
Confirm the tool still encrypts with the network connection disabled

Ask Who Holds the Key

Ask whether a reset reopens old ciphertext

Key ownership is the second question, and it usually decides the rest. Many zero-knowledge designs derive a key from your passphrase in the browser and never transmit it. That gives you real control and takes away recovery: nobody, including the operator, can rebuild the key from what the server stores.

Some services hold a copy of your key so they can reset a password or restore an account. That is a legitimate trade; read it as one. If an operator can recover your data on request, then so can anyone who gains the operator's access. Ask directly: can you decrypt my data without my passphrase?

Try it: ask the vendor whether a reset reopens old files.

Find out whether a password reset also reopens old ciphertext
Look for key escrow and recovery keys in the documentation
Decide whether recovery or sole custody matters more for this data

Check the Algorithms, Modes, and Parameters

Names, not hints

An encryption tool worth trusting names its primitives instead of hinting at strength. AES-256-GCM is specified in FIPS 197 and NIST SP 800-38D, and its authentication tag detects tampering. ChaCha20-Poly1305, specified in RFC 8439, suits systems without AES hardware acceleration. Key derivation matters too: PBKDF2 is defined in RFC 8018 and Argon2 in RFC 9106, and the iteration count or memory cost sets the price of guessing your passphrase.

Parameters belong in the documentation next to the algorithm names. A tool that says AES-256 but omits the mode, salt length, nonce handling, and derivation cost leaves you guessing about the parts that break.

Try it: look up the standard numbers, mode, salt and cost.

Look for FIPS 197, NIST SP 800-38D, RFC 8439, RFC 8018, or RFC 9106 by number
Check the authentication tag: GCM uses a 128-bit tag in the standard configuration
Treat vague strength claims without parameters as a missing answer

Match the Threat Model, Then Verify It

Verification means repeating a claim yourself

Start by writing down the adversary you are defending against: a stolen laptop, a shared computer, a subpoena to the provider, a network observer, or a colleague on the same account. No tool covers all of them. Client-side encryption handles several of these well and does nothing against a compromised endpoint. If recovery matters more than custody, pick a service that provides it and says so. Malicious extensions, keyloggers, and a hostile operating system see your plaintext before any cipher runs.

Verification means repeating a claim yourself on your own machine. The W3C Web Crypto API is documented on MDN; run the same primitive in your browser console: await crypto.subtle.generateKey({name:"AES-GCM",length:256}, true, ["encrypt","decrypt"]). For file formats, decrypt a sample with an independent implementation such as Node's crypto.createDecipheriv, and compare the result. Open source helps only when you can read the code that actually runs, so check the published source against the deployed bundle.

Try it: repeat one crypto call and compare it with another tool.

Scenario	What to verify
Lost or stolen device	The key is not stored with the ciphertext.
Shared computer	Closing the tab clears the input and key.
Provider breach	No server-side payload exists to steal.
Legal request to the provider	There is no key or plaintext to hand over.

Read the Retention and Deletion Policy

Expiry, deletion, and offline behaviour

Retention decides how long ciphertext, metadata, and logs survive. A tool that stores nothing has nothing to hand over, and one that keeps encrypted blobs needs a clear expiry rule. Look for a stated retention period, a delete that removes the object rather than hiding it, and a note on what remains in backups afterwards.

Offline behaviour belongs here too. If the page encrypts with the connection cut, the cryptography is local and the tool stays usable on a plane, in a locked-down network, or after the service disappears. A tool that fails without a network round trip is doing something on a server, whatever the interface suggests.

Try it: cut the network, encrypt something, and see what still works.

Find the retention period in writing, not in a help article
Test deletion and check whether the ciphertext disappears from your account
Load the page once, disconnect, and encrypt a test string

Frequently Asked Questions

How do I choose an encryption tool I can trust?

Start with location and key ownership, because those two answers rule most candidates in or out. Then require named algorithms with published parameters, a readable retention policy, and a way to test the encryption yourself. If any of those is missing, treat the gap as the answer.

What are the most important criteria for evaluating an encryption tool?

Five checks cover most of the decision: where encryption runs, who holds the key, which standard and parameters are used, what the service retains, and whether the threat model fits. Verifiability runs through all five: can you confirm the first four on your own hardware? Tools that answer all five in writing are rare, which is itself useful.

Does an encryption tool need to be open source to be trustworthy?

Open source makes independent review possible, but it is not proof on its own. A published repository only helps if you can confirm that the code you run was built from it and if someone qualified has actually reviewed the cryptography. Closed tools can still be honest; you then rely on documentation and your own network tests instead of code.

Related guides on keys and encryption models

Run the Checklist on a Real Tool

Open the browser tools, encrypt a short test string, and watch the network tab. No account is required.

Open the encryption tools

Read the security model Encrypt in your browser now