Encrypting text in the browser is a round trip with a guard: the plaintext is transformed into ciphertext with a key, and a 16-byte authentication tag is attached so that anyone who changes even a single bit of the ciphertext on the way is caught. AES Encrypt/Decrypt runs that round trip entirely in the browser with AES-GCM: a 12-byte plaintext becomes a 28-byte ciphertext, a 32, 48 or 64-character hex key selects AES-128, 192 or 256, and the 24-character IV is 12 bytes. The output is base64 โ 40 characters for that 12-byte example โ and the decryption side refuses anything that has been tampered with. Nothing leaves the machine.
What GCM Adds to the Block Cipher
AES by itself is a block cipher: it takes 16 bytes at a time and scrambles them through a fixed number of rounds โ 10 rounds for a 128-bit key, 12 for 192, 14 for 256. A block cipher alone does not hide the length of a message, does not accept a message that is not a multiple of 16 bytes, and cannot tell you whether the ciphertext was changed on the way. GCM adds three things on top of it. It runs the cipher in counter mode, so a message of any length flows through. It derives a keystream that is XORed with the plaintext, which is what hides the content. And it computes a 16-byte authentication tag over the ciphertext with a keyed hash. The tag is the guard: flip a single bit of the ciphertext and the decryption side throws instead of returning garbage. A plain hash generator computes unkeyed digests of the same family for integrity and deduplication, but a digest cannot be reversed, so hashing alone can never be encryption โ the GCM tag borrows the hash idea and keys it, which is what makes it safe to attach.
The Key, the IV, and the Pair That Must Not Repeat
The key is the material: 32 hex characters are 16 bytes, 48 are 24, 64 are 32, so the three legal lengths select AES-128, AES-192 and AES-256, and the key stays in a non-extractable handle inside Web Crypto after importKey, never stored or sent as text. The IV, the initialization vector, is 24 hex characters, 12 bytes, and it must differ from every other IV that was used with the same key. That is the pair that must not repeat: the same key with the same IV twice is the failure that breaks GCM, because the counter keystream would be identical in both runs and the second message would hand an attacker the ability to strip the first. The tool keeps a list of the key-IV pairs it has already used in the session and shows a warning the moment you try to encrypt again with one of them. For comparison, an HMAC generator uses the same kind of keyed hash for the opposite job: it authenticates a message without hiding it, so HMAC answers the question of whether the content is intact and from you, while GCM answers that plus the question of whether it is secret.
Where the Randomness Comes From
When the page loads, the tool fills the two fields for you: a 64-character random hex key, 32 bytes, and a 24-character random hex IV, 12 bytes, generated with the same Web Crypto getRandomValues path that underpins the encryption itself. The randomness is what keeps the IV unique: a 12-byte random IV has a negligible collision probability across a small number of messages, and a fresh key removes even that. If you generate identifiers in the same browser, the UUID generator pulls from the same randomness source for version 4 UUIDs, and the same caveat applies: randomness is a supply, not a setting, and the browser is the dispenser. Treat the two generated fields the way you would treat a passport โ they leave with you, and they are not to be shared.
Reading the Base64 Output
The ciphertext is binary, so the tool renders it as base64, the encoding that maps every group of three bytes onto four characters. That is why the 12-byte plaintext does not come back as 12 characters: 28 bytes of ciphertext, the 12 bytes plus the 16-byte tag, encode to 40 base64 characters, with the final group absorbing the remainder as padding. The growth is stable and predictable: 100 bytes of plaintext give 116 bytes of ciphertext, which is 156 base64 characters, and 1000 bytes give 1016, which is 1356 characters. The extra 16 bytes are the same tag every time, so for long messages the overhead is negligible and for short ones it is visible. When you need to hand the bytes to somewhere that expects the raw encoding, the base64 encoder/decoder converts between the text form and the other representations without touching the content.
The Key Is the Whole System
AES-GCM is only as strong as the key behind it, and a key is a secret in exactly the same sense a password is one: its strength is a function of length and unpredictability, and its management is a function of not repeating it and not writing it where anyone can read it. The tool does not judge your key โ it accepts any even-length hex string in the 32 to 64 range โ but the honest check is the one a password strength checker applies to passwords, translated to hex: a 64-character hex string that is a repeated pattern is 32 bytes of material and far less than 256 bits of entropy. If you need actual key material rather than a typed one, the password generator guide covers the same generation and storage discipline, and a random hex key is produced through the same one-click path.
Where AES Shows Up Outside the Box
The same AES-GCM primitive is not a browser toy: TLS uses AES-GCM as one of its core record ciphers, full-disk encryption on modern operating systems uses AES, usually in XTS mode, and the Web Crypto API that the tool calls is the same API that payment runtimes, sign-in flows and offline-first apps call for encrypted local storage. The point of this tool is to make that primitive inspectable: you can see the exact ciphertext, the exact tag overhead, and the exact failure mode of tamper detection, all in a text box. Tokens are the other visible face of the same stack โ a JWT decoder opens the header and payload of a token to show what is signed and what is not, which is the read-only twin of what encryption does in the write direction.