What AES Encryption/Decryption helps you do
Encrypt and decrypt text with AES in CBC mode using the browser's Web Crypto API. The key is a hex string of 16, 24 or 32 bytes, and the IV is a separate 16-byte hex value. The ciphertext is returned as Base64, with PKCS#7 padding applied by the browser.
Encryption and decryption run entirely in your browser. Your text, key and IV are not sent to Haivix.
How it works
Every operation runs in your browser, and the keys and plaintext stay on the device. The underlying libraries are fetched from a public CDN when the page loads, so the code itself comes from a third party at runtime; that is acceptable for learning and interoperability, not for high-assurance key handling. These are low-level primitives, not a complete protection scheme: CBC, ECB and RC4 provide confidentiality only, with no integrity check, so altered ciphertext may decrypt to something an application still accepts. Modern designs pair encryption with authentication, such as AES-GCM or ChaCha20-Poly1305, and keep keys in a dedicated store rather than a form field.
How to use AES Encryption/Decryption
- Enter the text to encrypt or the Base64 ciphertext to decrypt.
- Supply the hex key and the 16-byte hex IV.
- Run the operation in the chosen direction.
- Copy the Base64 ciphertext or the recovered plaintext.
When to use it
- Protect a short note or value before storing it.
- Decrypt a value you encrypted earlier with the same key and IV.
- Demonstrate symmetric encryption in a lesson.
- Check a round trip against a test vector.
- Encrypt a fixture for a local experiment.
- Inspect how CBC changes with a different IV.
When not to use it
- Do not use it for production secrets or key management.
- Do not reuse an IV with the same key; CBC leaks equality across messages.
- Do not expect integrity protection; CBC alone does not detect tampering.
Example
Encrypting a short sentence with a 32-byte key and a random IV returns Base64 ciphertext that decrypts back to the original only with the same key and IV. A different IV produces different ciphertext for the same plaintext. Using the wrong key length or a 15-byte IV is rejected before any crypto runs.
What you can do with AES Encryption/Decryption
- Encrypt text with AES-CBC.
- Decrypt Base64 ciphertext with the same key and IV.
- Accept 128, 192 or 256-bit keys in hex.
- Prefill random key and IV values.
- Validate key and IV lengths.
- Run the operation locally in the browser.
Example: know what you have before choosing an operation
Identify the input format. A raw key in hex, a passphrase and a PEM key are different things, and using one where another is expected produces garbage rather than an error.
Test with a known vector or a short round trip. Encrypt, decrypt and compare before using the tool on data you cannot afford to lose.
Never paste a production private key or long-lived secret into a web page. Use a throwaway key for experiments and a proper key store for real work.
Check the mode and padding against the system you are interoperating with. The same algorithm with a different mode is a different ciphertext format.
Prefer an authenticated mode for anything new. If the tool only offers CBC or ECB, treat the output as a demonstration rather than a protection mechanism.
Record the output encoding as well as the algorithm. Base64, hex and raw bytes are easy to confuse, and a format mismatch looks like a wrong key.
What to know before you start
- It is browser-based and best for casual protection, not for production secrets or key management.
- Losing the key or IV loses the data, and a weak key weakens the encryption.
- CBC provides confidentiality only; there is no authentication tag.
- The tool does not generate or store keys beyond the page session.
Common mistakes
- Treating the key as a passphrase; it must be hex bytes.
- Reusing the same IV for multiple messages.
- Losing the IV, which is required for decryption.
- Assuming CBC authenticates the ciphertext.
Troubleshooting
If the key is rejected, count the hex characters: 32, 48 or 64.
If the IV is rejected, it must be exactly 32 hex characters.
If decryption produces garbage, the key or IV is wrong, or the ciphertext was altered.
If decryption throws, the Base64 may be truncated or padded incorrectly.
Related standards and documentation
- FIPS 197 defines AES, and NIST SP 800-38A defines its common modes of operation.
- NIST SP 800-38D defines GCM, an authenticated mode suited to new designs.
- FIPS 186-5 covers digital signatures, including RSA and ECDSA.
- RFC 8017 defines RSAES and RSASSA, including PKCS#1 v1.5 and OAEP.
- NIST SP 800-57 describes key management and key lifetime practices.
- Check key and input formats.
- Round-trip before trusting.
- No integrity in CBC or ECB.
- Use AEAD for new work.