AES 在线加密解密
用密码或原始密钥对文本做 AES 加解密，支持 GCM / CBC / CTR；加密结果自带算法、盐与 IV，对方拿到后只需密码就能解开。
功能特性
AES-GCM（带认证，推荐）、AES-CBC、AES-CTR，支持 128 / 192 / 256 位密钥。
密码经 PBKDF2-HMAC-SHA256 派生（迭代 10 万 / 31 万 / 60 万次，随机盐 16 字节），也可直接填十六进制或 Base64 密钥。
默认输出自描述信封 JSON，内含算法、迭代次数、盐与 IV，对方只需密码就能解开，不必再手工对齐参数。
运算全部由浏览器 WebCrypto 完成，密码、密钥与明文不随请求发出，页面也不做存储。
使用步骤
不确定就选 AES-GCM；用密码记忆方便，用原始密钥便于与后端代码对齐。
在左侧写要加密的内容，填好密码后右侧自动出密文。
复制或下载整段信封 JSON——它已经包含解密所需的全部参数。
对方粘贴信封、填入同一密码即可；用「试解」按钮可把刚加密的结果直接搬去解密，自查往返是否正确。
适用场景
常见问题
AES-GCM、CBC、CTR 该选哪个？
默认选 AES-GCM。它是带认证的加密（AEAD），密码错误或密文被改动时认证标签校验会直接失败，你能立刻知道「解不开」；AES-CBC 与 AES-CTR 没有认证机制，密码错了同样会算出一段结果（多数是乱码，也可能是恰好合法的文本），页面在这两种模式下会额外提示这一点。
同一段明文加密两次，密文为什么不一样？
正常现象。每次加密都会新生成随机的盐（16 字节）与 IV，所以密文必然不同；否则相同明文会产生相同密文，攻击者据此就能判断出两段数据是否相同。解密所需的盐与 IV 都存在信封里，不影响还原。
什么叫「自描述信封」？
输出的 JSON 形如 {"v":1,"alg":"AES-GCM","kdf":"PBKDF2-SHA256","iter":310000,"salt":"…","iv":"…","ct":"…"}，把算法、密钥派生方式、迭代次数、盐、IV 与密文打包在一起。这样解密方只需要密码，不必再逐个参数对齐——「只有密文没有 IV / 盐」是在线加解密最常见的废纸场景。
能和 openssl 或后端服务互相解密吗？
可以，但必须把参数对齐：同样的分组模式、PBKDF2-HMAC-SHA256 派生、相同的迭代次数与盐、相同的 IV。注意两点差异：AES-GCM 的 16 字节认证标签在 WebCrypto 中是拼在密文末尾的（Node / openssl 需要单独取 authTag）；本页普通文本走 UTF-8 编码，解密端也必须按 UTF-8 还原。
密钥长度选多少位？
128 位（16 字节）、192 位（24 字节）、256 位（32 字节）在当下都算安全，AES 至今没有被有效的实际攻击。用密码派生时统一是 256 位；直接填原始密钥时长度必须是 16 / 24 / 32 字节，本页会校验并提示当前字节数。
密码会被记录或上传吗？
不会。加解密全部在浏览器内由 WebCrypto 完成，密码、密钥与明文都不随请求发出，页面也不写 localStorage / Cookie。代价是刷新页面后输入内容即丢失，请注意自行保存。