Encryption Basics in the Browser: Hashing, Symmetric Keys and What Stays Local

A hash such as SHA-256 maps input to a fixed-length digest and is designed not to be reversed. Encryption maps plaintext to ciphertext that can be reversed with the correct key. If a tool offers to encrypt a password and returns a short fixed string with no key, it is hashing, not encrypting. Use hashes for integrity checks and password storage only with a proper password-hashing scheme, not raw SHA alone.

AES and similar algorithms use the same key to encrypt and decrypt. That key must reach the other party without being intercepted, which is the hard part. Putting the key in the same email as the ciphertext, or hard-coding it into front-end JavaScript, cancels the protection. Browser tools are excellent for local experiments and for encrypting data before upload when you alone hold the key; they are not a substitute for a full key-exchange protocol.

RSA and elliptic-curve schemes use a public key anyone can encrypt with and a private key only the recipient should hold. That removes the need to ship a shared secret, but it introduces certificate and key-management problems instead. Never paste a private key into a random web form unless you generated it locally and trust the page completely.

Client-side encryption runs in JavaScript controlled by the page. A compromised script, a malicious extension, or an injected third-party library can read the plaintext before encryption or the key after generation. Local processing reduces server exposure; it does not create a trusted computing base. Treat the page origin as part of your threat model.

Encryption without integrity checking can still be manipulated. Modern practice prefers authenticated modes such as AES-GCM that detect tampering. A tool that only offers legacy modes without authentication is fine for learning demos and a poor default for real secrets. Prefer libraries and tools that make the safe mode the obvious mode.

Human passwords have low entropy and must be stretched with a password-based key derivation function before they become encryption keys. Feeding a short password directly into AES is a common mistake in homemade schemes. If a browser tool accepts a password, check whether it derives a key properly or just uses the password bytes as-is.

Use browser hashing for checksums and demos. Use browser symmetric encryption when you generate and keep the key yourself for local files. Use established end-to-end systems for messaging and collaboration. Do not invent a new protocol in a form field and then store the only copy of the key in the same browser profile.

Choosing AES-256 sounds strong until the key is in localStorage next to the ciphertext, or the page loads a third-party script that can read form fields. Write down who you are defending against: a curious sibling, a stolen laptop, a hostile server operator, or a network eavesdropper. Each adversary implies different controls. Algorithm choice is only one line in that list, and rarely the first line that fails.

A browser form that encrypts a note with a password is a fine teaching tool and a poor password manager. Production systems need key rotation, device sync, recovery paths and abuse monitoring. If you outgrow a local demo, migrate to a maintained application instead of bolting features onto a page that was never designed to hold long-lived secrets.