Asking whether AES or RSA is "better" is a bit like asking whether a hammer is better than a screwdriver — Encoding vs Encryption vs Hashing already drew the line between them: AES is symmetric (one key, both directions), RSA is asymmetric (a public key and a private key, each undoing what the other did). That difference isn't a tradeoff to weigh — it determines which one is even capable of the job in front of you.
At a glance
| AES | RSA | |
|---|---|---|
| Key | One shared secret key | A public/private pair |
| Speed | Fast — gigabytes per second on modern hardware | Slow — orders of magnitude slower, and slower still as data grows |
| Max data size per operation | Unlimited (streams in blocks) | A few hundred bytes at most, minus padding overhead |
| What it's actually used for | Encrypting the real, bulk data | Signing, and exchanging a small secret (usually an AES key) |
| Common key sizes | 128, 192, 256-bit | 2048, 3072, 4096-bit |
Why RSA can't just replace AES
RSA has a hard mathematical ceiling on how much it can encrypt in one operation — the plaintext has to be smaller than the key's modulus, minus padding overhead. In practice, RSA-2048 with OAEP/SHA-256 padding tops out around 190 bytes per encryption. That's not a tuning parameter or a library limitation; it's inherent to the algorithm. There's no version of "RSA-encrypt this 4 GB file" that works directly — not slowly, not eventually, not at all past that ceiling.
RSA is also simply slow relative to AES — encrypting with a public key and decrypting with a private key both involve modular exponentiation over very large numbers, orders of magnitude more expensive per byte than AES's block cipher rounds. Even without the size ceiling, using RSA for bulk data would be impractically slow for anything beyond a tiny payload.
Why AES can't just replace RSA either
AES has the opposite problem: it has no concept of "two different keys with two different capabilities." Whoever has the AES key can both encrypt and decrypt — full stop. There's no way to hand someone the ability to encrypt something to you without also handing them the ability to decrypt anything already encrypted with that same key. That asymmetry — encrypt-only for anyone, decrypt-only for the key's owner — is specifically what RSA (and public-key cryptography generally) exists to provide, and it's not something a symmetric algorithm can be configured to do at any key size.
The real pattern: use both, for different jobs
Every practical system that needs RSA's properties uses it to move a small AES key into place, then lets AES handle everything the RSA ceiling and speed can't — exactly what "every HTTPS connection" means in practice:
RSA never touches the actual page content, file, or message — only the small AES key that will. This is why HTTPS, PGP/GPG, and S/MIME all follow the same shape.
This is usually called hybrid encryption or envelope encryption: RSA solves the hard problem (getting a shared secret in place between two parties who've never met, without transmitting the secret itself in the clear), and AES solves the problem RSA is bad at (encrypting a large volume of data quickly). Real TLS handshakes today more often use elliptic-curve Diffie-Hellman instead of RSA for this exact step — faster, smaller keys for equivalent security — but the shape of the pattern is identical, and RSA key exchange is still common enough to matter.
Key sizes aren't directly comparable
"RSA-4096 is stronger than AES-256 because 4096 is a bigger number" is a natural assumption, and it's wrong — the two algorithms rely on completely different mathematical hardness assumptions, so their key sizes don't sit on the same scale at all. NIST publishes a rough comparable-strength table (SP 800-57) for exactly this reason:
| Symmetric security level | Equivalent AES key | Equivalent RSA key |
|---|---|---|
| 112-bit | — | 2048-bit |
| 128-bit | AES-128 | 3072-bit |
| 192-bit | AES-192 | 7680-bit |
| 256-bit | AES-256 | 15360-bit |
Read the bottom row carefully: matching AES-256's security level would need a 15,360-bit RSA key — large enough that essentially nobody actually uses RSA at that size in practice. RSA-4096, the largest size most tools (including this site's own generator) offer, sits between the 3072 and 7680 rows — comfortably past AES-128's level, well short of AES-192's. "Bigger RSA number" and "bigger AES number" simply aren't answering the same question.
Common mistakes
- Trying to RSA-encrypt a whole file directly. It fails past a few hundred bytes, or requires chunking that defeats the point — generate an AES key, encrypt the file with that, and RSA-encrypt only the AES key.
- Comparing key sizes across algorithms like they're the same unit. Use the NIST table above, not the raw numbers, when the actual question is "how do these security levels compare."
- Using one RSA key pair for both signing and encryption. Best practice is a separate pair per purpose — covered in RSA Key Pair Generator's own FAQ.
- Assuming a bigger AES key fixes a weak implementation. AES-256 with a reused IV or ECB mode is worse than AES-128 used correctly — key size isn't the only variable, covered in AES Encrypt/Decrypt's own notes on GCM vs CBC.
FAQ
Which one is more secure, AES or RSA?
Not a meaningful comparison on its own — they protect against the same class of attacker but solve different problems, and a real system almost always uses both together rather than choosing one.
Can RSA encrypt a whole file?
Not directly — RSA's plaintext size limit (a few hundred bytes at most, depending on key size and padding) rules it out. Real systems RSA-encrypt a randomly generated AES key instead, then AES-encrypt the actual file.
Is a 4096-bit RSA key stronger than AES-256?
No — per the NIST comparable-strength table above, RSA-4096 lands between AES-128 and AES-192's security levels. Matching AES-256 would take a 15,360-bit RSA key, which is not something anyone actually deploys.
Why does TLS use both?
For exactly the reasons above: an asymmetric algorithm (traditionally RSA, increasingly elliptic-curve Diffie-Hellman) establishes a shared secret between two parties who've never communicated before, and a symmetric algorithm (AES) then handles the actual traffic at the speed bulk encryption requires.
Try it yourself
AES Encrypt/Decrypt and RSA Key Pair Generator cover each half of this post directly — one encrypts real data with a passphrase-derived key, the other generates a real public/private pair as PEM, for signing or for wrapping exactly the kind of small secret this post describes. Both run entirely in your browser.