Hash Generator Guide
Use this guide to understand what each digest algorithm guarantees, why MD5 and SHA-1 are legacy-only, and how to use hashes correctly for checksums, integrity verification, and testing. Hashing runs entirely in the browser; the input is never transmitted.
Overview
A cryptographic hash maps any input to a fixed-size fingerprint. The security question is collision resistance: whether an attacker can craft two inputs with the same fingerprint. MD5 and SHA-1 have practical collision attacks, so the generator includes them only for compatibility with legacy systems, while SHA-256 and above remain safe for new work.
Usage decisions to review together
- Algorithm choice: Use SHA-256 or stronger for anything security-relevant; treat MD5 and SHA-1 as legacy compatibility only.
- Purpose: File integrity, content addressing, and test vectors are hash jobs; password storage is not — that needs bcrypt, scrypt, or Argon2.
- Comparison source: A checksum only proves integrity if the expected value comes from a trusted channel separate from the file itself.
Digest Algorithms and Status
| Algorithm | Output size | Current status |
|---|---|---|
| MD5 | 128-bit | Broken for collisions; legacy checksum compatibility only. |
| SHA-1 | 160-bit | Practical collision attacks demonstrated; deprecated for signatures. |
| SHA-256 | 256-bit | Current standard for integrity, signatures, and content addressing. |
| SHA-384 | 384-bit | SHA-2 family; common in TLS certificate signatures. |
| SHA-512 | 512-bit | SHA-2 family; strong margin and fast on 64-bit systems. |
Practical Verification Examples
sha256sum release.tar.gz
# compare against the published checksum from the vendor siteGet-FileHash .\release.zip -Algorithm SHA256Recommended Remediation Flow
- Standardize on SHA-256+ Update build scripts, download pages, and documentation to publish SHA-256 or SHA-512 checksums.
- Retire MD5/SHA-1 in new code Replace legacy digest calls in new systems; keep them only where an external protocol still requires them.
- Separate hashing from password storage Move any password storage using plain digests to a dedicated KDF such as bcrypt or Argon2 with per-user salts.
- Publish checksums over a trusted channel Serve expected hashes over HTTPS on a different path or domain from the artifact, or sign them.
Troubleshooting Common Issues
My hash does not match the published value
Mismatches usually come from input differences rather than algorithm bugs.
- Confirm you hashed the exact bytes — trailing newlines and encoding changes alter the digest.
- Check you used the same algorithm as the published value.
- Re-download the file; a partial download produces a different hash.
Two different texts give the same short prefix
Comparing only the first few characters of a digest is not a safe equality check.
- Always compare the full digest value.
- Use a constant-time comparison in code paths attackers can reach.
- Prefix matching is fine only for human eyeballing of low-stakes values.
Validation Checklist
Post-fix validation
- Confirm new integrity workflows publish SHA-256 or stronger checksums.
- Verify no new code path uses MD5 or SHA-1 for security decisions.
- Check password storage uses a dedicated KDF, not a raw digest.
- Re-generate digests after content changes and confirm consumers compare full values.
FAQ
Is my input sent to your servers?
No. Digests are computed locally in your browser using the Web Crypto API and a local MD5 implementation.
- The page works offline once loaded.
- No analytics event includes the input text or the digests.
- For sensitive material you can still prefer an offline CLI tool.
Can a hash be decrypted back to the input?
No. Hashes are one-way; there is no decryption, only guessing inputs and comparing outputs.
- Short or common inputs can be recovered via precomputed tables, which is why salts exist.
- Long random inputs are not practically reversible.
- This is also why plain hashes are unsuitable for password storage.