Client-Side AES-256 Encryption: How to Protect Text Without Trusting a Server

A few years ago I needed to send a colleague some credentials for a legacy system we were both working on. Not production secrets — more like the admin password for an internal test tool. The kind of thing you should not put in a chat message or email in plaintext, but also not important enough to justify spinning up a secrets management system just for this one handoff.

My solution at the time: zip the credentials into a file, encrypt with 7-Zip, and send. Clunky, but it worked. What I actually wanted was to take a string, encrypt it with a password, and send the resulting ciphertext. Something the recipient could decrypt with a tool and the password I would share separately.

That is exactly what the Text Encrypt & Decrypt tool does, using encryption that was previously only accessible through server-side code or native application cryptography libraries. The browser's Web Crypto API has made this genuinely practical, and the security is real — not toy-level crypto but the same algorithm used to protect classified information.

What AES-256-GCM Actually Means

Let me explain the algorithm name without getting into the mathematics, because the terminology matters for understanding what you are actually getting.

AES stands for Advanced Encryption Standard. It is a symmetric block cipher — symmetric meaning the same key encrypts and decrypts. It was selected by NIST (the US National Institute of Standards and Technology) in 2001 after an international competition, replacing the older DES standard. It is the dominant encryption algorithm globally.

256 refers to the key size in bits. AES supports 128, 192, and 256-bit keys. 256-bit is the strongest option. The number of possible 256-bit keys is 2²⁵⁶ — approximately 1.16 × 10⁷⁷. There are an estimated 10⁸⁰ atoms in the observable universe. Even with every atom in the universe acting as a supercomputer, brute-forcing a 256-bit key is not possible in any practical sense. The key length is not the weak point in AES-256.

GCM stands for Galois/Counter Mode. This is the mode of operation — how AES processes data that is longer than one 128-bit block. GCM is what is called an authenticated encryption scheme: it not only encrypts the data for confidentiality, it also produces an authentication tag that verifies the ciphertext has not been tampered with. If someone flips a bit in the encrypted output, decryption will fail with an authentication error rather than silently producing corrupted plaintext. This matters. An encryption scheme that does not authenticate can be manipulated in ways that expose information about the key or plaintext.

There are other modes — CBC is the most common alternative — but GCM is the modern recommendation. If you see AES-256-GCM, you are looking at well-chosen cryptography.

The Password Problem: Why PBKDF2 Matters

AES-256 takes a 256-bit key. Your password is not 256 bits — it is probably 8 to 30 characters of mixed case letters and numbers, which represents a much smaller key space. You cannot just feed the password directly into AES.

PBKDF2 (Password-Based Key Derivation Function 2) is the bridge. It takes your password, a random salt (a unique value generated per encryption that prevents identical passwords from producing identical keys), and runs them through a hash function many thousands of times. The result is a proper 256-bit key suitable for AES.

The "many thousands of times" part is intentional. PBKDF2 is designed to be slow. This is a feature, not a bug. If someone captures your ciphertext and tries to brute-force the password by trying every word in a dictionary, each attempt requires running PBKDF2 as many iterations as the original key derivation used — 100,000 iterations is a common setting. At 100,000 iterations, even a machine trying a million passwords per second takes about 17 minutes to exhaust a 100,000-entry dictionary. Weak passwords are still crackable, but the attack is far more expensive than it would be against raw AES keys.

The salt ensures that even if two people encrypt different messages with the same password "hello123", they get different ciphertext outputs, which prevents certain statistical attacks.

How the Web Crypto API Works Here

The browser's Web Crypto API (window.crypto.subtle) provides cryptographic operations that run natively in the browser's C++ engine, not in JavaScript. This matters because:

1. The performance is better. Native crypto is significantly faster than JavaScript implementations.
2. The security is better. The browser vendor has implemented and audited these algorithms. A JavaScript implementation might have subtle bugs. The platform implementation is tested against the same test vectors used to certify server-side libraries.
3. Nothing leaves the browser. There is no HTTP request. The encryption happens entirely on your machine.

The Text Encrypt & Decrypt tool uses crypto.subtle.importKey, crypto.subtle.deriveKey (for PBKDF2), and crypto.subtle.encrypt/decrypt for the actual AES-GCM operation. These are the same APIs used by password managers and end-to-end encrypted messaging applications.

Using the Tool

Open the Text Encrypt & Decrypt tool and you will see two main sections: Encrypt and Decrypt.

To encrypt:

1. Paste your text into the input field.
2. Enter a password. Choose something with meaningful length — 16+ characters is much stronger than an 8-character password for PBKDF2-derived key material.
3. Click Encrypt. The output field shows the ciphertext — a long string of what looks like random characters (it is Base64-encoded).
4. Copy the ciphertext.

To decrypt:

1. Paste the ciphertext into the decrypt input field.
2. Enter the same password used to encrypt.
3. Click Decrypt. If the password matches, the original plaintext appears.

If the password is wrong, decryption fails with an error — it does not silently produce garbled output, which is the correct behavior for authenticated encryption.

The tool stores nothing. There are no accounts, no logs, no server calls. Close the tab and the data is gone.

When Client-Side Encryption Actually Makes Sense

Client-side encryption is not the right tool for every situation. But there are clear cases where it is the right approach.

Sharing Sensitive Text Over Insecure Channels

You have credentials, API keys, private notes, or sensitive configuration that you need to send to someone. Email is not end-to-end encrypted (most implementations). Slack and Teams are encrypted in transit but readable by server administrators. SMS is worse.

Encrypting the text before sending means the channel carrying the ciphertext does not need to be secure. You can email the encrypted blob and text the password separately. Someone who intercepts the email has a string of characters that is computationally useless without the password.

This is not a perfect solution — the password channel needs to be trustworthy, and very weak passwords are still crackable. But it is significantly better than plaintext, and it uses zero infrastructure.

Encrypting Notes Before Storing in Cloud Services

You use Notion, Obsidian Sync, Apple Notes, or Google Keep. These services have access to your data — their servers process and store it. If you have notes that you genuinely want no third party to be able to read — medical notes, financial details, journal entries — client-side encryption before storage is the right model.

Encrypt the note, save the ciphertext to whatever cloud service you use. The service sees the ciphertext. You decrypt it when you need to read it, using a password only you know.

The friction is real: you can not full-text search encrypted notes without decrypting first, and losing the password means losing the note permanently. These trade-offs are worth understanding before committing to this workflow.

Personal Data Backups

If you back up to a shared drive, a cloud storage bucket, or a USB that might leave your possession, encrypting sensitive files before they go into storage is good practice. For single text blobs — passwords you are archiving, recovery codes, private keys — a text encryption tool is faster than spinning up a full encrypted archive.

Developer Workflow: Secrets in Config Files

Occasionally a developer needs to check in a secret to a repository because the deployment environment cannot accommodate environment variables or a secrets manager. This is not ideal, but it happens. Encrypting the value before committing, and documenting the decrypt step in the README with the password stored separately in a team password manager, is better than plaintext secrets in the repo.

This approach is not a substitute for proper secrets management. But it is better than nothing in constrained situations.

What Client-Side Encryption Cannot Protect Against

Being honest about limitations is part of using security tools responsibly.

Weak passwords. The encryption is only as strong as the password. AES-256 with a 6-character password like "abc123" is vulnerable to dictionary attacks. The mathematics of the algorithm are sound; the key derivation can only do so much with weak input material. Use a proper passphrase — something long, random, or otherwise hard to guess.

Compromise of your own device. If malware has keylogging capabilities or can read your clipboard, the encryption step is irrelevant — the attacker captures the plaintext before encryption or captures the password as you type it. Client-side encryption protects against interception in transit and unauthorized server access. It does not help if your machine is compromised.

JavaScript execution context attacks. In a browser, every browser extension has potential access to page content. A malicious extension could read the decrypted text out of the DOM before you copy it. If you are encrypting genuinely sensitive information, be aware of what extensions are running.

Loss of the password. There is no recovery mechanism. The tool has no account, no server, no way to reset a password. If you forget the password used to encrypt something, the ciphertext is unrecoverable. Write the password down somewhere safe before encrypting anything you need long-term.

AES-GCM vs. Other Approaches

You might wonder why not use RSA (asymmetric encryption) or something like GPG. The short answer is that AES is faster for bulk data encryption and simpler for the symmetric-key use case. RSA and GPG are designed for asymmetric scenarios where you want to encrypt something for someone without sharing a key first. For a shared-password "I encrypt, you decrypt" workflow, symmetric encryption is the right model.

The tool's use of AES-256-GCM specifically is a better choice than some older approaches:

• AES-256-GCM over AES-256-CBC: GCM provides authentication (tamper detection); CBC does not.
• AES-256-GCM over older or proprietary algorithms: AES is an open standard, published and reviewed by cryptographers worldwide.
• PBKDF2 over a direct hash: PBKDF2's computational cost makes brute-force attacks much more expensive.

This is a well-constructed implementation of modern symmetric encryption. It is not a home-brew cipher or an obscure algorithm — it is the combination of primitives recommended by NIST and used in real-world security applications.

Related Tools

Password Generator — Generate strong, random passwords. If you are choosing a passphrase to use for encryption, you want something with genuine randomness rather than a word you came up with yourself.

Password Strength Checker — Before using a passphrase for encryption, check how strong it actually is. Entropy matters here more than most contexts.

Hash Generator — Generate SHA-256, MD5, and other hashes from text. Related but distinct from encryption — hashing is one-way and does not require a key.

Base64 Encoder — Encrypted output is typically Base64-encoded. If you need to understand or manipulate the encoding separately from the encryption, the Base64 tool handles that.

FAQ

What is AES-256 encryption? AES-256 is the Advanced Encryption Standard using 256-bit keys. It is a symmetric cipher — the same key encrypts and decrypts — used to protect sensitive data by governments, financial institutions, and secure applications worldwide. The 256-bit key space is large enough to make brute-force attacks computationally infeasible.

Is client-side encryption actually secure? Yes, when implemented correctly using established algorithms. The browser's Web Crypto API provides the same cryptographic primitives as server-side libraries. The security depends primarily on password strength — the algorithm itself is not the weak point. The advantage is that no server ever sees your data.

What does GCM add to AES-256? GCM (Galois/Counter Mode) is an authenticated encryption mode. It not only encrypts for confidentiality but also produces a verification tag that detects tampering. If the ciphertext is modified before decryption, decryption fails with an error rather than silently producing corrupted output.

Why can't I recover encrypted data if I forget the password? The encryption key is derived from your password. Without the password, the key cannot be reconstructed, and without the key, the ciphertext cannot be decrypted. There is no server-side recovery mechanism — by design. This is the trade-off of client-side encryption: maximum privacy means no recovery path.

How should I share encrypted text securely? Send the ciphertext through your normal channel (email, chat). Send the password through a separate channel — a phone call, a different app, or in person. Keeping ciphertext and password separated means that access to either one alone is not enough to recover the plaintext.

Final Thoughts

Client-side encryption using AES-256-GCM is not a silver bullet. It does not protect against a compromised device, it does not work if you choose a weak password, and it creates a recovery problem if you lose the password. These are real limitations worth understanding.

But for the use cases it is designed for — sharing sensitive text over untrustworthy channels, encrypting notes before cloud storage, archiving secrets without a dedicated secrets manager — it is a well-implemented, cryptographically sound option. The Text Encrypt & Decrypt tool uses the same algorithms that protect real-world security applications, running entirely on your device with no data leaving your browser.

That combination of accessibility and genuine security is what makes it worth using.