Hash algorithms are not interchangeable labels for “make a checksum.” The right choice depends on whether you need legacy compatibility, accidental-corruption detection, collision resistance, a digital-signature digest, or password storage. Z Tools keeps MD5 and SHA-1 for compatibility but labels their security limitations and defaults to SHA-256.
Decision table
| Algorithm | Use today | Avoid for |
|---|---|---|
| MD5 | Legacy/non-adversarial checksum compatibility | Collision-resistant security, signatures, certificates |
| SHA-1 | Legacy protocol/object compatibility only | New security designs |
| SHA-256 | General modern integrity/signature digest | Password storage by itself |
| SHA-384 / SHA-512 | Protocols that require larger SHA-2 outputs | Password storage by itself |
Reference timing from the shipped verification run
The bundled benchmark records Node.js 24.14.1/V8 Web Crypto reference timings, not browser performance. Each 1 MiB case ran three bounded iterations:
| Algorithm | Input | Average |
|---|---|---|
| SHA-256 | 1 MiB | 2.1918 ms |
| SHA-384 | 1 MiB | 4.3559 ms |
| SHA-512 | 1 MiB | 3.3164 ms |
Do not use those numbers to rank algorithms on your device: hardware, engine, warm-up, scheduling, and implementation differ. The value of the table is reproducibility and bounded methodology, not a universal speed league table.
Why MD5/SHA-1 remain in the tool
Checksums published by old download mirrors, APIs, and build systems still use them. Removing the algorithms makes comparison harder; hiding their weaknesses makes the tool misleading. The compromise is compatibility with strong labeling.
File hashing vs text hashing
The file picker hashes raw file bytes locally. Text hashing first converts the JavaScript string to UTF-8 bytes. Those inputs are not interchangeable: line endings, normalization, text encoding, or a final newline can change the digest. When verifying a downloaded artifact, hash the file bytes—not copied text from an editor.
A hash is not a MAC
If an attacker can replace both a file and the displayed SHA-256 value, a plain hash provides no authenticity. Authentication requires a trusted signature or a keyed construction such as HMAC. Similarly, passwords should use a slow, salted password KDF such as Argon2id/bcrypt/scrypt rather than plain SHA-256.
Primary references
NIST publishes the Secure Hash Standard as FIPS 180-4. Protocol-specific requirements should override generic advice because the verifier and signer must agree on the exact algorithm and encoding.