The Complete AES Encryption Guide

AES (Advanced Encryption Standard) was designed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, and was originally called Rijndael. In 2001, after a 5-year public competition and evaluation, the U.S. National Institute of Standards and Technology (NIST) officially published it as Federal Information Processing Standard FIPS 197, replacing the aging DES (Data Encryption Standard).

AES is called a "block symmetric cipher" for two key reasons:

• Block: AES processes fixed 128-bit (16-byte) data blocks. If the plaintext length is not a multiple of 16, padding is needed.
• Symmetric: The same key is used for both encryption and decryption. This means communicating parties must share the key over a secure channel, but the algorithm is extremely fast and suitable for bulk data encryption.

AES supports three standard key lengths: 128-bit (16 bytes, 10 rounds), 192-bit (24 bytes, 12 rounds), and 256-bit (32 bytes, 14 rounds). Longer keys provide higher security but slightly increase computational overhead.

In practical deployment, AES has become the de facto global encryption standard. It is widely used in TLS 1.3 / HTTPS web encryption, WPA2 / WPA3 wireless networks, BitLocker / FileVault disk encryption, VPN tunnel encryption, database field protection, mobile app data encryption, e-commerce payment systems, and smart cards & hardware security modules — essentially every scenario requiring data confidentiality. Its security has withstood over 20 years of public scrutiny by the global cryptography community and is still considered secure today.

Our online AES tool preserves the practical value of the algorithm while providing developers with one-stop online encryption, decryption, and result copying.

The core operation of AES can be summarized in one sentence: A 128-bit plaintext input is transformed through multiple rounds to produce a 128-bit ciphertext. Understanding this process is essential for using AES correctly.

AES uses a Substitution-Permutation Network (SP Network) structure, and each round consists of four steps:

• SubBytes (Byte Substitution): Each byte is mapped to another byte by looking it up in a fixed 16×16 S-box. This provides confusion capability, making the relationship between key and ciphertext complex.
• ShiftRows (Row Shifting): Each row of the 4×4 state matrix is cyclically shifted by a different offset (row 0 not shifted, row 1 shifted left by 1 byte, row 2 shifted left by 2 bytes, row 3 shifted left by 3 bytes), providing diffusion capability.
• MixColumns (Column Mixing): Each column of the state matrix is multiplied by a fixed polynomial over the GF(2^8) finite field, mixing the 4 bytes within each column. This provides diffusion capability, ensuring that a single plaintext bit change affects many ciphertext bits.
• AddRoundKey: Each byte of the state matrix is XORed with a round key derived from the main key.

Key Expansion is another important component of AES: the main key is expanded into a series of round keys through a specific algorithm. For AES-128, 11 round keys are needed (1 initial round + 10 rounds), each 128 bits. The expansion process uses the same S-box as SubBytes and adds Rcon (round constants) to ensure each round key is different.

The complete encryption flow:

• Initial Round: Only AddRoundKey (XOR with round key 0).
• Rounds 1–9 (AES-128 example): SubBytes → ShiftRows → MixColumns → AddRoundKey.
• Round 10 (Final Round): SubBytes → ShiftRows → AddRoundKey (no MixColumns).

The decryption process is similar but in reverse order and with inverted round keys: inverse S-box, inverse row shifting, inverse column mixing, and round keys used in reverse order.

After understanding this structure, you can accurately answer why AES block size is fixed at 128 bits, why identical plaintexts produce identical ciphertexts in ECB mode, and why IV is so important in CBC mode.

AES by itself only defines how to encrypt a single 16-byte block. When encrypting variable-length data, a mode of operation must be used. Different modes have different characteristics in terms of security, implementation complexity, parallel processing capability, and error propagation.

① ECB (Electronic Codebook)

ECB is the simplest mode: each plaintext block is encrypted independently. Advantages are simplicity, parallelizable decryption, and no error propagation. The key disadvantage is that identical plaintexts produce identical ciphertexts, easily leaking data patterns. A classic example: encrypting an image with large repetitive areas using ECB still reveals the original outline after encryption. Not recommended for sensitive data.

② CBC (Cipher Block Chaining)

Each plaintext block is XORed with the previous block's ciphertext before encryption. The first block is XORed with an Initialization Vector (IV). CBC is one of the most commonly used modes today, with the advantage that it hides plaintext patterns — identical plaintext blocks produce different ciphertexts. Disadvantages: encryption cannot be parallelized (though decryption can), and the IV must be random (unpredictable). CBC with PKCS7 padding is the classic combination in web development.

③ CTR (Counter Mode)

CTR uses AES as a stream cipher, generating a keystream by encrypting an incrementing counter value and XORing it with the plaintext bit by bit. Advantages: no padding needed, encryption and decryption are identical, fully parallelizable, and provide random access to ciphertext. Disadvantage: very sensitive to counter repetition (if the same counter value is used with the same key, plaintext is directly leaked). CTR is the basis of GCM mode.

④ OFB (Output Feedback Mode)

OFB is similar to CTR — it is also a stream cipher mode, but generates a keystream by continuously feeding back the encryption output as the next input. Advantages: no padding needed, no error propagation. Disadvantages: not parallelizable and sensitive to IV-key pair repetition. OFB is suitable for channels with unstable quality (such as satellite communications) but is gradually being replaced by CTR or GCM in modern systems.

⑤ CFB (Cipher Feedback Mode)

CFB feeds the ciphertext of the previous block back as input, encrypts it, and XORs it with the current plaintext to produce the current ciphertext. Like the above, it is a stream cipher mode and requires no padding. CFB has multiple variants (CFB-8, CFB-64, etc.) and is suitable for scenarios where data is processed byte-by-byte or bit-by-bit (such as network packets).

⑥ GCM (Galois/Counter Mode)

GCM is an authenticated encryption mode that provides both confidentiality and integrity authentication. It adds a GHASH (Galois Hash) operation on top of CTR mode to generate an authentication tag. The recipient verifies the tag during decryption — if the tag does not match, decryption is rejected, effectively defending against ciphertext tampering attacks. GCM also supports AAD (Additional Authenticated Data) — data that is not encrypted but whose integrity needs to be protected (such as HTTP headers, protocol metadata). GCM is the most recommended mode today and is widely used in TLS 1.3, IPsec, SSH, and wireless communications.

Padding method selection is also important. Common padding schemes:

• PKCS7 / PKCS5: Most common, each missing byte is filled with a value equal to the number of missing bytes. For example, if 3 bytes are missing, fill with 0x03 0x03 0x03.
• ZeroPadding: Fill with zero bytes, but trailing zeros in the original data cannot be distinguished.
• ANSIX923: Fill the last byte with the padding length, other positions with zeros.
• ISO10126: Fill the last byte with the padding length, other positions with random bytes.

In stream modes (CTR, OFB) and authenticated modes (GCM), padding is typically not required.

Our tool supports all major modes above with various encoding and padding switches, making it easy to quickly verify implementations in different scenarios.

As the de facto global encryption standard, AES application scenarios cover virtually every domain requiring data confidentiality. Here are the 7 most typical real-world use cases:

① HTTPS / TLS Network Transmission Encryption

In HTTPS communication between browsers and servers, after the TLS handshake completes, session data is typically encrypted with AES-GCM or AES-CBC. AES's high performance enables it to easily handle hundreds of megabytes or even gigabytes of network traffic per second, making it the key enabler of HTTPS performance.

② WPA2 / WPA3 Wireless LAN Encryption

WPA2 protocol for home and enterprise Wi-Fi is based on AES-CCMP (CTR mode + CBC-MAC), and WPA3 further uses AES-GCMP. All data packets between the router and terminals are encrypted with AES before transmission, effectively defending against wireless eavesdropping.

③ BitLocker / FileVault Full-Disk Encryption

Windows BitLocker and macOS FileVault use AES to encrypt the entire disk at the block device layer. Even if the hard drive is stolen, an attacker cannot recover the data without the key. This is a foundational measure for enterprise endpoint security and Data Loss Prevention (DLP).

④ Sensitive Field Encryption in Databases

Sensitive fields such as ID numbers, mobile phone numbers, bank card numbers, customer addresses, and health records are encrypted with AES before being written to the database. Even if the database is breached, an attacker cannot directly read the sensitive information. Combined with a Key Management System (KMS), this enables more comprehensive data masking and compliance.

⑤ VPN Tunnel Encryption (IPsec / OpenVPN / WireGuard)

In IPsec VPN and OpenVPN protocols commonly used for corporate remote work, AES performs symmetric encryption of session data. The WireGuard protocol defaults to ChaCha20-Poly1305 but also supports AES-GCM in most implementations.

⑥ Mobile App & API Data Protection

Beyond HTTPS transport-layer encryption, developers often add application-layer AES encryption for critical business data (such as payment tokens and user credentials). This provides "defense in depth" — even if one layer is breached, another layer still protects user data.

⑦ Smart Cards, HSMs, and IoT

Bank cards, SIM cards, USB security keys, and Hardware Security Modules (HSMs) typically have built-in AES hardware acceleration engines for high-performance encryption in constrained environments. In Internet of Things (IoT) scenarios, lightweight devices also extensively use AES to protect sensor data, firmware updates, and device communication.

In short: Whenever you need symmetric encryption for data, AES is the first choice for mature performance and ecosystem support.

In practical applications, choosing the right key length and mode affects both security and performance. Here is a comparison and recommendations:

Key Length Comparison

• AES-128: 128-bit key, 10 rounds. Security strength is sufficient to resist all known attacks today (including near-term quantum computing threats). It is also used by the U.S. federal government for SECRET-level information. Best performance (fewest rounds) with minimal key management overhead.
• AES-192: 192-bit key, 12 rounds. Higher security strength. Mainly used when compatibility with specific systems (such as certain government and enterprise systems) is required. Less commonly used in general web development.
• AES-256: 256-bit key, 14 rounds. Provides the highest security level and resistance to quantum computing threats, suitable for TOP SECRET-level information. Performance is slightly lower than AES-128 (more rounds), but the difference is minimal on modern CPUs.

Mode Comparison & Recommendations

• Authenticated encryption (most recommended): Choose GCM. Provides both encryption and integrity authentication, defending against ciphertext tampering. Widely used in TLS 1.3, modern APIs, and mobile platforms.
• Traditional file and data encryption: Choose CBC + PKCS7. Most mature ecosystem with best compatibility. Note that IV must be random.
• Stream cipher mode / random access ciphertext: Choose CTR. No padding, parallelizable.
• Compatibility with legacy systems: You may need ECB, OFB, or CFB, but these are not recommended in new systems.

IV Management Best Practices

• CBC mode: The IV must be random and unpredictable (use a cryptographically secure random number generator, such as crypto.getRandomValues() or openssl_random_pseudo_bytes()). The IV does not need to be secret and can be transmitted along with the ciphertext.
• CTR / GCM mode: The IV (called nonce in GCM) must never repeat under the same key. If the nonce repeats, an attacker can compute the keystream and recover the plaintext. Recommended practice: use a 12-byte (96-bit) counter or random nonce.
• ECB mode: No IV needed. But precisely for this reason, ECB is not recommended for sensitive data.

Practical Recommendations

• Scenario involves new systems, modern protocols, high security & integrity requirements → Choose AES-128-GCM or AES-256-GCM.
• Scenario involves legacy system compatibility, file encryption, traditional APIs → Choose AES-128-CBC + PKCS7.
• When in doubt, prefer GCM — it provides both confidentiality and authentication, and is the safest and most mainstream choice today.

Even with a standard algorithm like AES, incorrect usage can lead to serious security vulnerabilities. Here are 5 practical tips to help you avoid common pitfalls:

① Use a Cryptographically Secure Random Number Generator

When generating keys and IVs, never use ordinary random numbers (such as JavaScript's Math.random() or Java's java.util.Random). The output of these generators is predictable, and an attacker can reproduce your "random" values. Use the operating system-provided Cryptographically Secure Pseudo-Random Number Generator (CSPRNG): in browsers use crypto.getRandomValues(), in Node.js use crypto.randomBytes(), and on Linux read from /dev/urandom.

② Manage Keys Properly — Never Hardcode

The key is the core of AES security. Never hardcode keys in source code, configuration files, or frontend JavaScript. Recommended options: Key Management Systems (KMS such as AWS KMS, Aliyun KMS, HashiCorp Vault), Hardware Security Modules (HSMs), environment variables (for development environments only), or cryptographically secure Key Derivation Functions (KDF like Argon2, PBKDF2, scrypt, bcrypt) to derive keys from user passwords. Keys must be rotated periodically and access must be minimized (least privilege principle).

③ Prefer Authenticated Encryption (AEAD) Modes

If your system supports it, prefer AES-GCM over AES-CBC. GCM provides both confidentiality and integrity authentication, effectively defending against ciphertext tampering attacks (such as padding oracle attacks and bit-flipping attacks). In CBC mode, if you don't have a separate MAC (Message Authentication Code), an attacker may be able to gradually recover plaintext by sending carefully crafted ciphertext and observing decryption failure messages.

④ Use Standard Libraries and Audited Implementations

Never implement AES yourself (or any cryptographic primitive). Use widely audited and tested standard libraries: Web Crypto API or crypto-js in JavaScript, javax.crypto in Java, the cryptography module in Python, and the crypto/aes package in Go. These implementations have been validated by millions of developers.

⑤ Ensure Parameters Are Identical Between Encryption and Decryption Sides

The most common reason for AES decryption failure is mismatched parameters among the key, mode, padding method, IV, and encoding format (Hex / Base64 / UTF-8). When designing protocols or APIs, explicitly declare all encryption parameters (for example: AES-256-CBC/PKCS7, IV is a 16-byte random value prepended to the ciphertext, ciphertext output in Base64). Establish clear documentation and unit tests to ensure that both encryption and decryption implementations are identical.

🔒 Local Browser Processing: Our AES tool runs entirely in your browser. All encryption and decryption operations are performed locally in the JavaScript engine. Your plaintext, ciphertext, keys, IVs, AAD, and tags are never uploaded to any server, nor are they recorded in any logs. The tool works even without an internet connection.

🛡️ Safe Usage Recommendations: When handling sensitive data with this tool, we recommend using privacy mode with browser extensions disabled, and ensuring your device is free of malware. Do not process highly sensitive information on public or untrusted computers. Clear your browser cache after use and close the page.

⚡ High-Performance Computing: The AES algorithm is designed to be extremely efficient, often accelerated by dedicated AES-NI (AES New Instructions) hardware on modern CPUs. Our tool uses a standard JavaScript implementation that can process tens of megabytes of data per second on a typical laptop — more than enough for daily development and testing.

🌐 Open Source & Transparent: We use industry-standard encryption implementations, with algorithm logic fully transparent to all users, ensuring no hidden behavior. Data security and privacy are our core commitments.

⚠️ Legal Compliance Notice: Please ensure you comply with the laws and regulations of your country and region when using this tool. This tool is intended for legal data protection, development testing, and learning research purposes only. Any use for illegal purposes is strictly prohibited.

💡 Final Reminder: Cryptography is a deep discipline. This article provides conceptual introduction and practical advice and cannot replace professional security auditing. When deploying encryption schemes in production systems, we strongly recommend consulting professional cryptographers or security engineers. Our online AES tool can assist you in daily development and learning, but production environment security requires systematic protection.