AES-GCM decrypt

Output from the AES-GCM encrypt tool on this site, or anything written in the same layout: a 16-byte salt, then a 12-byte IV, then AES-GCM ciphertext with its tag. It rederives the key with PBKDF2-HMAC-SHA256 at 210,000 iterations. It cannot open a password-protected ZIP, an encrypted PDF, a 7z archive or a disk volume. Those are different formats with different key derivation.

Because the AES-GCM tag check did not pass. The rest of the message says wrong password, or the file is corrupted or not AES-GCM encrypt output. Those cases look identical from here. GCM fails closed: it refuses rather than handing back plausible garbage, so a single flipped byte anywhere in the file produces the same refusal as a wrong password. Check the password first, then check the file downloaded whole.

The refusal is "input is too short to be an AES-GCM encrypt output (needs salt + iv + tag)". Any real output is at least 44 bytes: 16 of salt, 12 of IV, 16 of tag. Anything smaller cannot be parsed at all, so the tool stops before it touches your password. You normally see this when the wrong file was dropped, or when a download was cut short.

No. There is no hint, no recovery and no brute force here. The file holds only salt, IV and ciphertext. Nothing in it can confirm a password except trying it, and every attempt costs 210,000 PBKDF2 iterations in your own browser. If the password is gone, the plaintext is gone with it.

Your input name with .aesgcm removed, so notes.txt.aesgcm comes back as notes.txt. If the input does not end in .aesgcm, the tool appends .dec instead, so blob.bin becomes blob.bin.dec. The name comes from the file you dropped, never from anything stored inside the ciphertext, because no name is stored there.

No. Decryption runs in a Web Worker in this tab using crypto.subtle. The ciphertext, the password and the recovered plaintext all stay in your device memory, and nothing is uploaded. The site works offline after the first visit, so you can disconnect the network and decrypt anyway.