Hashes/Crypto

AES Encrypt/Decrypt

Encrypt and decrypt text with AES-GCM or AES-CBC using a password (key derived via PBKDF2).

AES is the standard for symmetric encryption: the same password is used to both encrypt and decrypt. This tool derives an encryption key from your password with PBKDF2 and encrypts text with AES-GCM or AES-CBC — all locally in your browser.

How to use it

Common uses

Things to keep in mind

The IV (initialization vector) must be unique for every encryption performed with the same key — reusing a key+IV pair in GCM completely breaks the encryption's security.

AES-CBC without a separate integrity check (a MAC) is vulnerable to ciphertext-tampering attacks — that's why GCM, which combines encryption and authentication in one mode, is the safer default.

Article about this tool: AES: how symmetric encryption works

Frequently asked questions

What key sizes does AES support here, and which should I use?

AES supports 128, 192, and 256-bit keys. AES-256 is the common recommendation for new applications, since 128-bit is already considered secure but 256-bit gives extra margin with negligible practical cost.

What's the difference between the cipher modes (like CBC, GCM)?

GCM authenticates the ciphertext as it encrypts, so it also detects tampering, making it the recommended default. CBC only encrypts and needs a separate MAC for integrity, and requires a random IV per encryption to stay secure.

Is my key or plaintext sent anywhere?

No. All encryption and decryption run locally in your browser via the Web Crypto API — nothing is uploaded to a server.

Why shouldn't I use ECB mode?

ECB encrypts each block independently and identically, so identical plaintext blocks produce identical ciphertext blocks — this leaks the structure of the data (for example, repeating patterns in an image remain visible even when encrypted). CBC or GCM with a unique IV avoid this problem.

What happens if I reuse the same IV with the same key?

For GCM, this is a critical mistake — reusing a key+IV pair completely compromises both the confidentiality and authenticity of the encryption. An IV must always be unique for every encryption performed with the same key.

Articles: Hashes/Crypto

Hash Generator: how MD5, SHA-1, and SHA-256 differ from each other

Why MD5 is still used to verify file integrity, but not for passwords.

Checksum Verifier: how to check that a file isn't corrupted

Why a matching checksum confirms a file's integrity, but not who created it.

HMAC: how a keyed hash differs from a regular hash

Why a plain SHA-256 doesn't protect against message tampering, but HMAC does.

Bcrypt: why passwords are hashed slowly, not quickly

Why fast SHA-256 is a bad choice for passwords, and slow bcrypt is the right one.

UUID: how identifiers that almost never repeat are generated

Why UUID v4 can be generated independently on millions of machines without collision risk.

Password Generator: what actually makes a password strong

Why a long dictionary-word password is stronger than a short one with symbols and digits.

Argon2: why this algorithm won the password hashing competition

How Argon2 defends better against GPU-based attacks than older password hashing algorithms.

Scrypt: why the algorithm needs so much memory

Why scrypt deliberately demands a lot of memory to make cracking on ASIC devices harder.

TOTP: how one-time codes in authenticator apps work

Why the code in Google Authenticator works offline and syncs with the server only via time.

PBKDF2: the oldest key-stretching standard

Why the recommended PBKDF2 iteration count keeps growing every year.

X.509: what's inside an SSL certificate

What exactly the browser checks in a site's certificate before showing the green padlock.

PGP: how public-key and private-key encryption works

Why you can freely share a PGP public key but never the private one.