MD5/SHA/HMAC 哈希、AES 加解密、随机密码生成与 JWT 解析，全部在本地计算、内容不上传。AES 支持口令模式（PBKDF2 + AES-256-GCM）与原始密钥模式（128/192/256 位，ECB/CBC/CFB/OFB/CTR）。
五件事，都是开发与日常里高频的小需求：算哈希、做 HMAC 签名、对称加解密、生成强密码、把 JWT 拆开看看里面写了什么。这些内容原本多半要装个命令行工具或找个在线网站，而不少在线网站是把内容发到它自己的服务器上算的。
这里的每一个字节都在你的浏览器里处理：哈希、加解密、随机数全部由本页的 JavaScript 与浏览器内置的 Web Crypto 完成。服务端只提供工具目录与使用策略，不接触你输入的任何内容。
哈希的作用是把任意长度的内容压成固定长度的指纹。同样的输入永远得到同样的输出，而输入改一个字，输出就会面目全非。所以它适合回答一个问题：这两份内容是不是一模一样。
但哈希不等于加密：它不可逆，也不需要密钥。校验文件完整性、比对两份数据、给接口做签名摘要，都用它；需要把内容还原出来，就得用加密。
如果你只是想把一段文字加密后发给人，用「口令加密」。它把口令经 PBKDF2-SHA256 迭代 60 万次派生成 256 位密钥，再用 AES-256-GCM 加密。GCM 是带认证的加密方式：密文被改动一位，解密就会直接报错，而不是解出一堆乱码。这一点在「发给别人」的场景里很重要。
如果你的系统里已经有固定的密钥，或者要解密别人用某个工具生成的密文，用「原始密钥 / IV」模式。它支持 AES-128/192/256 与 ECB、CBC、CFB、OFB、CTR 五种模式，填充可选 PKCS7、Zero、ISO10126、ANSIX923 或不填充，足以对接大多数既有实现。
需要提醒的是 ECB：它把每个 16 字节分组独立加密，相同的明文块会得到相同的密文块。加密一张图片时，你往往还能看出原图的轮廓。它只应该出现在必须兼容老系统的场合。CBC 解决了这个问题，但 CBC 没有完整性校验，密文被改只会解出乱码、不会报错，所以对「防篡改」有要求时仍应选 GCM。
这是同类工具里最容易踩的坑，所以这里把它显示出来而不是藏起来。AES-128 需要 16 字节密钥，AES-256 需要 32 字节。当你填的内容不足时，工具会用 0x00 在末尾补齐；超出时，超出的部分会被截掉。IV 同理，固定 16 字节。
补零的后果是密钥强度大幅下降。一个 8 字节的口令补成 16 字节后，后 8 字节是已知的 0x00，实际强度只有原来的一半。所以页面上会显示「实际密钥」的十六进制值，那是真正参与运算的字节，建议核对一遍。正式使用时请填满长度：Hex 编码下 AES-256 就是 64 个字符。
IV 不参与密钥派生，它的作用是让相同的明文在相同密钥下得到不同的密文。同一个密钥下重复使用同一个 IV，会让两张密文的异或等于两段明文的异或，等于把内容泄露出去。CTR 模式尤其要注意这一点，它的 IV 就是计数器起点。
很多网页工具的随机密码其实是假的：它们用 Math.random()，而它的种子可以被预测，攻击者拿到几个输出就能推算出后续的字符。这里用的是 crypto.getRandomValues，由操作系统提供的密码学随机源。
第二个容易被忽略的细节是取模偏差。如果直接把随机数对字符池大小取余，当 2 的 32 次方不能被字符池大小整除时，靠前的字符出现概率会略高。单看一位无所谓，但密码生成器里这个偏差会被放大成「某些字符几乎不出现」，可用字符数就变少了。这里的做法是拒绝采样：落在不能整除的尾巴上就丢弃重抽。
页面会显示估算的熵值（长度 × log2(字符池大小)）。但熵只反映这个字符串有多随机，不反映它是否已经泄露、是否在别处被用过。长度够长且不复用，比追求特殊符号更重要。
JWT 的前两段（header 与 payload）只是 Base64url 编码的 JSON，不是加密。任何人拿到一个 token 都能解开看内容，所以不要在 payload 里放不该外泄的东西。
本工具不验证签名，因为它需要对应的公钥或共享密钥，而 JWT 的签名校验必须在你自己的服务端做。更关键的是：即使一个在线工具「验证通过」，也不能说明这个 token 有对应的权限，因为 issuer、audience、过期之外的业务校验它一概不知道。
所以这里只做一件事：把 Base64 解开，把 exp、iat、nbf 换算成你能读懂的时间。看到 role: admin 时请记住，那只是「这段文本这么写」，不是「这个 token 真有管理员权限」。
本工具免费、免登录、不限次数。哈希、加解密、随机数全部由浏览器完成，没有任何内容会被上传——你可以打开开发者工具的网络面板自己确认：除了页面本身与工具目录接口，没有别的请求。
有一个例外需要说清楚：MD5 与原始密钥模式是纯 JavaScript 实现，所以在 http:// 环境下也能用；而 SHA 系列、HMAC 与口令加密依赖浏览器的 crypto.subtle，它只在 HTTPS 或 localhost 下存在。页面顶部会检测这一点并直说哪些功能不可用，而不是让按钮点了没反应。
一样。两者都是对同一串字节做 MD5，输出都是小写十六进制。注意命令行是对文件字节计算，本工具默认对文本按 UTF-8 编码后再计算，所以只要输入的内容等价，结果就一致。中文内容请确认两端都是 UTF-8。
多半是编码差异：同一个汉字在 UTF-8 下是 3 字节，在 GBK 下是 2 字节，算出来的哈希自然不同。本工具按 UTF-8 计算，并在输入区标注了当前编码。如果你的原始数据是十六进制，请切到「十六进制」输入模式，让它按字节计算而不是按文本。
不能。密文里带着版本号、随机盐与 IV，但没有记录算法与参数（PBKDF2-SHA256 60 万次、AES-256-GCM）。第三方工具不知道该用哪套参数，所以解不开。反过来，别的工具生成的密文这里也解不开。这是刻意的取舍：要跨工具互通就得用标准封装格式（如 JWE），那需要引入额外的库。
因为每次都会生成新的随机盐和随机 IV。这正是正确做法：如果两次结果相同，别人一对比就能判断两段内容是不是同一份。解密时这两项都从密文里读出来，所以你不需要记住它们。
不能。工具里没有保存任何口令或密钥，也没有「找回」的入口。忘了口令，那段密文就永久打不开了。建议用一句好记但别人猜不到的话作为口令，并和密文分开渠道传递。
新系统一律用 GCM（或其他的 AEAD 模式）：它同时提供加密与完整性校验，密文被篡改会直接报错。CBC 只在需要对接老系统时使用，并且要注意它不做完整性校验——密文被改动时通常解出乱码，也可能只改掉最后一个分组的一部分内容，你未必能发现。
因为密钥不足所需长度，工具按通行做法用 0x00 补齐了。这是为了让「随便填个短口令」也能跑通，但补零会明显降低密钥强度。正式使用时请把密钥填满：AES-128 是 16 字节、AES-192 是 24 字节、AES-256 是 32 字节，Hex 编码下分别对应 32、48、64 个字符。
浏览器的 crypto.subtle 只在安全上下文（https 或 localhost）里存在。普通 http 页面拿不到它，所以 SHA 系列哈希、HMAC 与口令加密不可用。MD5 与原始密钥 AES 是纯 JavaScript 实现，不受这个限制；密码生成与 JWT 解析也不需要它。页面顶部会明确列出哪些可用。
只要随机源可信、长度足够，就不现实。16 位、四类字符（剔除易混淆后 80 个可选字符）的熵约 101 位，暴力枚举需要尝试约 2 的 101 次方。真正的风险通常不是被算出，而是复用、被钓鱼、或存在明文里。本工具不保存生成的密码，关掉页面就没有了。
说明那个服务端没有校验 exp，或者用的是另一个字段。exp 只是「建议的过期时间」，是否遵守由服务端决定。另外注意 exp 是秒级时间戳，本工具已按本地时区换算；如果你看到的时间差了几个小时，多半是时区认知差异，不是解析错了。