"Encrypted in your browser" sounds like a complete answer to privacy. It is a real and useful property — but it protects against specific threats and not others. This article explains how browser-side encryption works using the AES Encrypt & Decrypt tool on Zerethon Tools as a concrete example, then lays out what it does and does not protect.

How the encryption works

Modern browsers include the Web Crypto API (crypto.subtle), a native implementation of standard algorithms. The Zerethon tool uses it in three steps:

  1. Derive a key from the password. Passwords are short and guessable, so they are never used as keys directly. The tool generates a random 16-byte salt and runs PBKDF2-SHA-256 with 100,000 iterations to stretch the password into a 256-bit key. The iterations make each password guess deliberately slow; the salt means the same password produces a different key every time.
  2. Encrypt with AES-256-GCM. A fresh random 12-byte IV (initialisation vector) is generated for every encryption. GCM is an authenticated mode: besides hiding the data, it adds a tag that detects any change to the ciphertext. Decrypting tampered data fails loudly instead of producing garbage.
  3. Package the result. The output is base64(salt ‖ iv ‖ ciphertext). Salt and IV are not secret — they are needed to decrypt — so storing them alongside the ciphertext is standard practice.

Randomness for the salt and IV comes from crypto.getRandomValues(), the browser's cryptographically secure generator. None of the input, password or output is sent to a server.

What "client-side" protects

  • The tool's operator cannot see your data. It never leaves the device, so it is not logged, stored, or exposed in a server breach.
  • The network cannot see your data. Nothing containing the plaintext crosses the network to be intercepted.
  • The ciphertext is safe to store or send through untrusted channels, as long as the password is strong and shared separately.
  • Tampering is detected, thanks to GCM's authentication tag.

What it does not protect

  • A weak password. PBKDF2 slows guessing; it does not make "123456" safe. An attacker with the ciphertext can try passwords offline as fast as their hardware allows. Use a long random password — for example from a password generator — and send it through a different channel than the ciphertext.
  • A compromised device or browser. Malware, a malicious extension with access to the page, or a keylogger can read the plaintext and password before encryption happens.
  • A changed page. You trust that the JavaScript you received today is the same honest code as yesterday. A server compromise could serve a modified script. Mitigations exist (HTTPS, a strict Content Security Policy, subresource integrity), but this is the fundamental limit of any web-delivered crypto. For high-stakes secrets, use an audited, installed tool.
  • Copies elsewhere. The clipboard, browser history, screenshots and the place you paste the output all hold copies outside the tool's control.
  • Metadata. Ciphertext length reveals roughly how long the message is.

How to judge any "in-browser" tool

  1. Check the network. Open developer tools → Network, use the tool, and confirm no request carries your input.
  2. Check the algorithm. Look for named, standard algorithms (AES-GCM, PBKDF2/Argon2) and the Web Crypto API — not custom schemes or Math.random().
  3. Check the format. A random salt and IV per encryption should be part of the output; if encrypting the same text twice gives the same result, something is wrong.
  4. Match the tool to the stakes. Fine for sharing a moderately sensitive note; not a replacement for a password manager, full-disk encryption or an audited end-to-end messenger.

Hashing is not encryption

A related confusion: hashes such as SHA-256 (try the SHA-256 Hash Generator) are one-way fingerprints, not encryption — there is no key and no way back. They are right for checking integrity ("is this the same file?") and, with a slow algorithm like bcrypt or Argon2, for storing passwords. They are wrong for anything you need to read again.

Summary

Browser-side encryption removes the server and the network from the list of things you must trust with your data. It does not remove your device, your password, or the integrity of the page itself. Used with a strong, separately shared password, it is a sound way to protect moderately sensitive text; for anything more, use dedicated, audited software.