Two AES tools produce output that looks identical, and one of them will let an attacker silently change your message. The difference is not the key size everyone argues about. It is the mode, and it decides whether tampering gets noticed at all.
Here is the short version. Use GCM for anything new. CBC hides your data and does nothing to prove it arrived unchanged, and that gap has broken real systems for twenty years.
What is an authentication tag, and why does it change everything?
An authentication tag is a short checksum that only someone with the key could have produced. GCM generates one over the whole message and stores it alongside the ciphertext, sixteen bytes on the end.
When you decrypt, that tag is checked first. If a single bit anywhere has changed, the check fails and you get nothing back. Not a partial message, not garbage — nothing.
CBC has no equivalent. It will happily decrypt something an attacker modified and hand you the result, and depending on what changed, the result may look almost right. That is the part people underestimate: silent corruption is more dangerous than a loud failure.
The trade is that you cannot tell a wrong key from a modified message, because both fail the same check. Our decrypt a string and see tool is built around that limit rather than pretending it away.
Which AES mode to use, and when the answer is not GCM
Pick GCM unless something stops you. That covers new applications, browser tools, APIs, and anything where you control both ends.
Three situations genuinely force CBC. A file format that specifies it. An existing system whose stored data you cannot re-encrypt. A hardware device with no GCM support, which still exists in industrial and payment equipment.
In those cases, add authentication separately and apply it to the ciphertext rather than the plaintext. Getting that order wrong reintroduces the exact problem you were avoiding, which is a large part of why the industry stopped assembling this by hand.
One more caveat we would rather state than bury. GCM is unforgiving about its starting value: reuse one with the same key and the damage is far worse than the equivalent mistake in CBC. Every tool should generate a fresh random one per message, and ours does.
Is AES-256 better than AES-128 in any way that matters?
Barely, and not in the way the marketing implies. Both are out of reach of brute force by an enormous margin, and no realistic increase in computing power changes that.
AES-128 arguably has the cleaner internal structure of the two, which surprises people. AES-256 uses more rounds and a more complex key schedule, and that schedule has attracted more theoretical criticism than anything in the 128-bit version.
We use 256 anyway. It costs almost nothing on modern hardware, it satisfies procurement checklists, and it removes an argument we would rather not have. What it does not do is make up for a short password, which is the actual weak point in every tool of this kind.
If a page leads with the key size and says nothing about the mode or the key derivation, that tells you something about how carefully the rest was built. We go through the other signals worth checking in how much any of this protects you.
Padding: the quiet reason CBC keeps failing
CBC works on fixed sixteen-byte blocks, so anything not a multiple of sixteen has to be padded out. That padding has to be removed on the way back, and the removal step is where the trouble lives.
If a system reveals whether the padding was valid — through an error message, a status code, or just by responding faster — an attacker can use that single bit of information repeatedly. Thousands of guesses later they have your plaintext without ever knowing the key.
This is not a museum piece. Padding oracle attacks have broken TLS implementations, framework session cookies and enterprise software within the last decade, repeatedly, in systems built by people who knew what they were doing.
GCM has no padding. It encrypts a stream of any length directly, so the entire class of attack has nowhere to live. That, more than raw speed, is the argument.
Speed, and why the benchmark you read is probably irrelevant
GCM is usually faster on modern processors, because both the encryption and the authentication run on dedicated instructions and can work in parallel.
For the work most people do, none of it matters. We measured the actual AES step on a 2.6 MB file in a browser: three milliseconds. The key derivation in front of it took sixty-seven, more than twenty times longer, and that step is deliberately slow.
So the honest ranking is: your password first, the key stretching second, the cipher mode third, and the key size a distant fourth. Almost every article on this topic gets that order backwards.
What this means for the tools on this site
Our text and file encryption both use AES-256-GCM through the browser's own Web Crypto, with the key stretched from your password by PBKDF2. Nothing here is a custom construction, which is deliberate — bespoke cryptography is where things break.
The tag is why encrypt text in your browser can promise that a modified message will be rejected rather than quietly mangled. It is also why file decryption reports a truncated download as truncated, instead of blaming your password.
Worth separating from all of this: hashing is not encryption and has no key. If you want a fingerprint of a file rather than a locked copy, generate a SHA-256 hash does that job and nothing else.
The choice in one line
Use GCM, generate a fresh nonce every time, and spend your remaining attention on the password instead of the key size.
Modes are the part of cryptography where careful people still make mistakes, which is why using a mode that removes whole categories of mistake is worth more than any number of extra bits. And once the message is encrypted, the hard problem is getting the key to the other end — a question no cipher mode can help with.