在线做 AES 对称加解密。可配置链路支持密钥长度（128 / 192 / 256 位）、分组模式（CBC / ECB / CTR / OFB / CFB）、填充方式（PKCS#7 / Zero / ISO10126 / Ansix923 / 不填充）、真实的 16 字节 IV，以及明文与密文两侧的字符集（UTF-8 / GBK / UTF-16LE / Base64 / Hex）；密钥和 IV 都可以用 [HEX]: 前缀直接粘十六进制原始字节。另有 TripleDES、RC4、Rabbit、Salsa20、ChaCha20、AES-GCM/SIV/KW 等历史算法，保留原有实现以便解开旧密文。验证一段密文、调试接口加密、临时保护一段配置时用，全程在浏览器本地完成。
工具界面在页面加载完成后显示在本段下方，可以直接使用。所有计算都在你的浏览器本地完成，输入的内容不会上传到服务器。
在线做 AES 对称加解密。可配置链路支持密钥长度（128 / 192 / 256 位）、分组模式（CBC / ECB / CTR / OFB / CFB）、填充方式（PKCS#7 / Zero / ISO10126 / Ansix923 / 不填充）、真实的 16 字节 IV，以及明文与密文两侧的字符集（UTF-8 / GBK / UTF-16LE / Base64 / Hex）；密钥和 IV 都可以用 [HEX]: 前缀直接粘十六进制原始字节。另有 TripleDES、RC4、Rabbit、Salsa20、ChaCha20、AES-GCM/SIV/KW 等历史算法，保留原有实现以便解开旧密文。验证一段密文、调试接口加密、临时保护一段配置时用，全程在浏览器本地完成。
输入：
NIST SP 800-38A 的 AES-128-CBC 官方向量：密钥 [HEX]:2b7e151628aed2a6abf7158809cf4f3c，IV [HEX]:000102030405060708090a0b0c0d0e0f，位数 128 bit，模式 CBC，填充「不填充」，明文编码 Hex 并填入 6bc1bee22e409f96e93d7e117393172a输出：
7649abac8119b246cee98e9b12e9197d（密文表示选 Hex）这段密文可以直接拿去和 OpenSSL、Java、Python 的实现对照：openssl enc -aes-128-cbc -nopad -K 2b7e... -iv 0001... 的输出与它逐字节一致。
这几乎都意味着参数不匹配：密钥不对、IV 不对、模式选错（对方是 CBC 而你选了 ECB），或者填充方式与加密方不一致。分组密码解密本身不会校验口令，只有当解出来的末尾字节不符合填充规则时才会被判定失败，所以它其实是「参数对不上」的信号，而不是「密文坏了」。
可以，前提是五项参数对齐：密钥长度、模式、填充、IV、字符集。Java 的 Cipher.getInstance(AES/CBC/PKCS5Padding) 用的是 PKCS#5/7 填充，Node 的 createCipheriv 默认也是 PKCS#7；这两者都能用「AES（可配置）+ CBC + PKCS#7」解开。密文如果是 Base64，把输出格式选 Base64；如果是十六进制就选 Hex。
它声明「后面这串是原始字节的十六进制表示」，与字符集下拉框无关。比如 [HEX]:2b7e151628aed2a6abf7158809cf4f3c 就是 16 个字节，不会被当成 32 个字符的文本。前缀后面只允许十六进制与空白，出现别的字符会直接报错并指出是哪个 —— 否则密钥录错了照样能加密，只是对方永远解不开。
历史算法是原有实现，它们把「自动生成随机 nonce 并前置到密文」写进了算法名里（AES-GCM、AES-CTR 都是），如果改成显式 IV，以前所有密文都会解不开。所以这里并存两条链路：要精确控制参数就用可配置那条，要解旧密文就切到历史算法对应的名字。
可以，但要先按你选的编码变成字节：一个汉字在 UTF-8 里占 3 字节、在 GBK 里占 2 字节。所以「8 个汉字」在 GBK 下正好 16 字节（AES-128 刚好），在 UTF-8 下是 24 字节（AES-192 刚好，选 128 位就会被截断）。跨系统对接用十六进制密钥最不容易出岔子。
不会。AES 计算全部在你的浏览器里跑，没有任何网络请求，密钥也不会写进 localStorage，关掉页面就什么都不剩。