Encrypt Text in Your Browser Without Sending It Anywhere

You want to send a short secret to a coworker over a channel you don't fully trust. Slack DM, email, a sticky note on a shared doc. What you don't want is to paste it into some random website that promises "client-side encryption" and then ships it to an analytics endpoint.

Good news: browsers have had real cryptography built in for years. The API is called WebCrypto, and for the 99% case of "encrypt a string with a passphrase," it's actually pleasant to use.

What WebCrypto Actually Is

window.crypto.subtle is the browser's implementation of low-level crypto primitives, written in C/Rust inside the browser engine. It's audited, hardware-accelerated where available, and — critically — it won't let you accidentally do something catastrophically wrong like reuse a nonce.

You don't touch OpenSSL. You don't pull in a 400KB crypto library. You call subtle.encrypt(...) and get back a promise with bytes.

Why AES-GCM, Specifically

If you've read any crypto tutorial from 2010, you've seen AES-CBC with a separate HMAC. That pattern works, but it's easy to mess up (padding oracles, wrong MAC order, forgetting to authenticate the IV).

AES-GCM replaces the whole sandwich. It's authenticated encryption — meaning the ciphertext comes with a built-in tag that verifies integrity. If anyone flips a bit in the output, decryption throws instead of silently returning garbage.

• Modern: standardized by NIST, used by TLS 1.3 by default
• Fast: has dedicated CPU instructions on every laptop made after ~2011
• Single primitive: no separate MAC to forget

The one rule: never reuse a nonce (IV) with the same key. The text-encrypt tool generates a fresh 12-byte random IV for every encryption, so you don't have to think about it.

The Passphrase Problem

Here's the awkward part. AES-GCM wants a 256-bit key — 32 random bytes. Humans want to type correct-horse-battery-staple. These are not the same thing.

You bridge the gap with a key derivation function (KDF). The tool uses PBKDF2 with SHA-256. PBKDF2 takes your passphrase, a random salt, and an iteration count, then chews on them for a while to produce a proper key.

Why the chewing? To make brute force expensive.

Why 200,000 Iterations

OWASP's 2023 guidance for PBKDF2-SHA256 is 600,000 iterations. Some tools still ship with 10,000 (which was reasonable in 2010 and embarrassing now). The text-encrypt tool uses 200,000, which sits in the practical middle:

• Fast enough that decrypting on a phone feels instant
• Slow enough that an attacker with a single RTX 4090 can't brute-force a 40-bit entropy passphrase in an afternoon

Is 200k "enough"? It depends on who's attacking you. For a coworker who shoulder-surfed your screen, yes. For a nation-state with a GPU cluster, your passphrase matters far more than the iteration count.

Threat Model: What This Actually Protects

Be honest about what you're buying.

It protects against:

• The ciphertext being read in transit or at rest
• An adversary who captures the message but doesn't have the passphrase
• A curious sysadmin reading your Slack logs
• Old backups being exposed in a breach

It does NOT protect against:

• A keylogger on your machine (it captures the passphrase)
• Shoulder-surfing while you type the passphrase
• Malware that screenshots your clipboard
• Your coworker pasting the decrypted result into a chat window anyway
• Coercion ("tell me the passphrase or else")

Cryptographers call this last category "rubber hose cryptanalysis." No amount of AES iterations helps.

When to Reach for the Tool vs. Something Else

Use the browser encrypt tool for:

• One-off secrets shared between two people who can agree on a passphrase out-of-band
• Quick protection of a snippet before pasting into a less-trusted channel
• Storing a short note in a sync'd doc where you don't fully trust the host

Don't use it for:

• Encrypting databases — use column-level encryption or KMS
• File-level encryption at rest — use age or your OS's native tools
• Anything where key management needs to scale past 2 humans

If you just need to prove a message wasn't tampered with (not hide it), HMAC is the right primitive. Webhook signatures are the classic example — Stripe, GitHub, and friends all use HMAC-SHA256.

The Takeaway

WebCrypto is good. AES-GCM is the right default. 200,000 PBKDF2 iterations is a reasonable balance for in-browser work, but your passphrase is doing most of the security lifting. And no amount of encryption saves you from typing the secret into a phishing page.

Encrypt when it helps. Don't let the vibe of encryption lull you into pasting sensitive stuff into places it doesn't belong.