内容摘要：打开浏览器，搜“AES在线加密”，前几个结果里至少有一半会在你输入密钥后把数据发到服务器上。这事我测试过——用开发者工具抓包，明文密钥和待加密内容清清楚楚躺在POST请求体里。工具站说“本地计算”，但

打开浏览器，加密解密搜“AES在线加密”，工具前几个结果里至少有一半会在你输入密钥后把数据发到服务器上。加密解密这事我测试过——用开发者工具抓包，工具明文密钥和待加密内容清清楚楚躺在POST请求体里。加密解密工具站说“本地计算”，工具但网络面板不会撒谎。加密解密

真正的工具纯前端AES工具，逻辑必须全部跑在浏览器里。加密解密判断方法很简单：断网，工具再操作一遍。加密解密如果还能正常加解密，工具说明JavaScript的加密解密crypto库在干活。如果转圈报错，工具那你的加密解密密钥已经离开过你的电脑了。

Web Crypto API 是唯一靠谱的底层

浏览器原生支持的 crypto.subtle 接口，是现在做在线AES工具最稳的方案。它不需要加载任何第三方库，性能也好。但有个坑：这个API只在HTTPS页面可用，HTTP环境下 crypto.subtle 直接是undefined。所以那些部署在HTTP上的工具站，要么用了CryptoJS之类的纯JS实现，要么干脆把计算扔给后端。

模式选择上，CBC和GCM是两种常见路线。CBC需要额外处理IV（初始化向量），GCM自带认证标签。很多在线工具默认用CBC，因为兼容性广，但如果你自己写工具，GCM更省心——它同时保证机密性和完整性，不用再单独算HMAC。

密钥长度不是越长越安全

AES-128和AES-256在理论上都不可暴力破解。实际场景里，128位密钥足够用，256位反而可能因为密钥派生函数（比如PBKDF2的迭代次数不够）引入弱点。我见过一个工具站，用户输入“123456”当密码，它直接补零到32字节当AES-256密钥用。这种操作等于把256位的安全强度拉到和“123456”一个水平。

正确的做法是：用户输入的口令，必须经过KDF处理。PBKDF2、scrypt、argon2都行，迭代次数至少10万次起步。在线工具如果跳过这一步，加解密速度飞快，但安全性形同虚设。

IV和Salt不能省

CBC模式下，同一个密钥配同一个IV加密相同明文，密文完全一样。攻击者不需要解密，光看密文重复就能推断出内容规律。所以IV必须随机生成，每次加密都不同，并且和密文一起存储或传输。Salt同理，用于密钥派生时防止彩虹表攻击。

我拆解过一个开源在线工具的实现，它把IV硬编码在JavaScript里，所有用户共用同一个值。这种设计，加密等于没加密。好的工具会在每次加密时调用 crypto.getRandomValues() 生成新IV，然后把IV拼接在密文前面一起输出。

实际使用中的几个细节

输出格式要明确。Base64和Hex是两种常见编码，但有些工具不标注用的是哪种，用户复制密文到另一个工具解密时直接报错。靠谱的做法是让用户选，或者自动检测。

填充方案也得说清楚。PKCS#7是主流，但Web Crypto API的AES-CBC默认就是PKCS#7，不需要手动处理。如果你用CryptoJS，得确认它默认的Pkcs7和Web Crypto的兼容。

还有个容易被忽略的点：字符编码。JavaScript里字符串是UTF-16，加密前必须转成UTF-8字节数组。有些工具用 charCodeAt() 直接取码点，遇到中文或emoji就出错。正确做法是用 TextEncoder 编码。

自己搭一个更放心

与其赌某个在线工具不偷数据，不如自己写一个单HTML文件。核心代码不到50行：crypto.subtle.importKey 导入密钥，crypto.subtle.encrypt 加密，crypto.subtle.decrypt 解密。IV用 crypto.getRandomValues(new Uint8Array(16)) 生成。密钥派生用PBKDF2，迭代次数设20万。整个文件离线可用，扔U盘里随身带。

在线工具不是不能用，但得知道它背后在干什么。断网测试、抓包看请求、检查IV是否随机——这三步做完，基本能筛掉90%的坑货。