How Password-Based File Encryption Works with AES-256-GCM
A file encryption tool scrambles the contents of any file with a password so that only someone who knows that password can read it again, and it does the reverse to recover the original. This one uses AES-256-GCM, the same authenticated cipher that secures HTTPS connections, combined with a strong key-derivation step, and it runs entirely inside your browser so the file never travels across the internet. People reach for a tool like this to protect a document before emailing it, to store a sensitive backup in cloud storage without trusting the provider, or to hand a file to a colleague over an untrusted channel where interception is a real concern.
The mechanism has two stages. First, your password is stretched into a 256-bit encryption key using PBKDF2 with HMAC-SHA256 and 600,000 iterations, the count OWASP recommends as of 2023, together with a random 16-byte salt; the deliberately high iteration count makes brute-forcing the password slow and expensive for an attacker. Second, the file is encrypted with AES-256-GCM using a random 12-byte initialization vector. GCM is authenticated encryption, meaning it produces a 16-byte tag that is checked on decryption; if the password is wrong or even a single byte of the encrypted file was altered, the tag check fails and the tool refuses to produce output rather than handing back garbage. The output file packs a small header — a magic marker, a version byte, the salt, and the IV — in front of the ciphertext, so decryption knows exactly how to reverse the process.
Walk through a round trip. You pick a file, type a strong password twice, and click encrypt; the tool derives the key, encrypts the bytes, and downloads a new file with an .hze extension whose layout is the 4-byte magic, 1 version byte, 16-byte salt, 12-byte IV, and then the ciphertext plus its authentication tag. To recover it, you switch to decrypt mode, choose the .hze file, and enter the same password; the tool reads the salt and IV from the header, re-derives the identical key, and decrypts. If you compare the SHA-256 of the original and the decrypted output they match byte for byte, confirming a lossless round trip. Enter the wrong password and the GCM tag check fails immediately, producing a clear wrong-password-or-corrupted-file error and never a damaged output file.
A freelancer sending a signed contract to a client can encrypt the PDF and share the password over a separate channel like a phone call, so intercepting the email alone reveals nothing. Someone backing up a password vault export or tax documents to a consumer cloud drive can encrypt them first, keeping the cloud provider and anyone who breaches it from reading the contents. A journalist or researcher moving sensitive source material on a USB stick gains protection if the drive is lost, since the file is unreadable without the password. In each case the appeal is that the encryption happens locally, so the plaintext never leaves the device and there is no server that could be compelled or breached.
The single most important caveat is unmissable: if you lose the password, the data is gone permanently. There is no reset link, no backdoor, and no recovery path, which is exactly what makes the encryption trustworthy, so write the password down somewhere safe before closing the tab. A second point worth understanding is why GCM specifically: plain AES-CBC has no integrity check, so a wrong key or a flipped bit silently produces garbled output that looks like data but is not, whereas GCM's authentication tag turns any tampering or wrong password into a clean, detectable failure. Because WebCrypto needs the whole file in memory to encrypt or decrypt, very large files may be slow on devices with limited RAM. Everything runs through your browser's built-in WebCrypto engine, and your file and password never leave the tab.
