文本哈希计算
Text Hash
算出字符串的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 和 CRC-32，输出可选大写或 Base64。
一次用 MD5、SHA-1、SHA-256、SHA-384、SHA-512和CRC-32 对文本或文件做哈希，并能把结果和你粘贴的校验和比对。文本按 UTF-8 字节哈希，其他任何工具说「对字符串做了哈希」时指的也是这个。
输入
拖入一个文件来算校验和
在这个标签页里读取，不上传。
文本按 UTF-8 字节做哈希，这也是别的工具说“给字符串算哈希”时的意思。
摘要
粘贴一个公布的校验和，对上的那一行会亮起来。
| 算法 | 摘要 | 复制 |
|---|---|---|
| MD5造一次碰撞很便宜。当校验和还行，签名和密码就别用了。 | ||
| SHA-1碰撞已经被实际做出来过。老的校验和还能用，新的东西别碰。 | ||
| SHA-256 | ||
| SHA-384 | ||
| SHA-512 | ||
| CRC-32这是检错码，不是哈希。两个文件可能碰巧撞上同一个值，故意撞就更容易。 |
输入
0 B
来源
文本框
怎么用
输入文本或拖入文件
所有算法同时计算，所以没有一个会选错的算法选择器。拖入的文件在这个标签页里读取，从不上传。
粘贴公布的校验和
「比对」框会点亮匹配的那一行，所以你不必知道发布者用的是哪种算法——也不必用肉眼比对 64 个十六进制字符。
需要 Base64 时切换输出格式
小写十六进制、大写十六进制和 Base64。摘要是同样的字节；变的只是写法。
常见问题
我该用哪一个？
没有别的要求就用 SHA-256。MD5 和 SHA-1 存在实际可行的碰撞攻击——发现意外损坏没问题，用在任何有人可能故意构造第二个文件的场合就不行。CRC-32 根本不是哈希；它是一种检错码。
我能用它给密码做哈希吗？
能，但你不该存储结果。密码需要一个慢的、加盐的函数——bcrypt、scrypt、Argon2——正因为 SHA-256 快：一块 GPU 每秒算几十亿次。本站的 bcrypt 工具才是对的页面。
为什么同样的文本在别处得到不同的哈希？
几乎总是末尾的换行，或者不同的编码。`echo "abc"` 发四个字节，`echo -n "abc"` 发三个，存成 UTF-16 的文件和同样文本的 UTF-8 是完全不同的字节。哈希是对字节做的，不是对你看到的东西。
计算哈希时我的文件会上传吗？
不会。哈希在这个标签页的字节上运行，SHA 家族走浏览器自己的 WebCrypto。这也是它断网也能用的原因。
可以从这些接进来
文件校验和
File Checksum
不限大小地流式哈希文件，并和你粘贴进来的期望值当场比对。
HMAC 生成
HMAC Generator
按选定的哈希算法和密钥编码算出消息的 HMAC，用来核对 webhook 签名。
bcrypt 与 argon2 校验
bcrypt & argon2 Checker
用指定 cost 对密码做 bcrypt 哈希，并把密码和现有的 bcrypt 哈希比对；argon2 认得出来但不计算。
哈希类型识别
Hash Identifier
按长度、字符构成和前缀推测一段哈希是哪种算法生成的，按可能性排序。
接下来
这些工具吃得下当前工具的产出，结果可以直接送过去。
bcrypt 与 argon2 校验
bcrypt & argon2 Checker
用指定 cost 对密码做 bcrypt 哈希，并把密码和现有的 bcrypt 哈希比对；argon2 认得出来但不计算。
文件校验和
File Checksum
不限大小地流式哈希文件，并和你粘贴进来的期望值当场比对。
哈希类型识别
Hash Identifier
按长度、字符构成和前缀推测一段哈希是哪种算法生成的，按可能性排序。
HMAC 生成
HMAC Generator
按选定的哈希算法和密钥编码算出消息的 HMAC，用来核对 webhook 签名。
Base64 编码解码
Base64 Encoder & Decoder
对文本和文件做 Base64 与 Base64URL 编解码，UTF-8 处理正确。
curl 转代码
curl to Code
把一条 curl 命令转成 fetch、axios、Python requests、Go、PHP 或 PowerShell 代码。