A cryptographic hash function takes an input of any size and produces a fixed-size output (the digest). Two properties matter: the same input always produces the same digest, and finding two different inputs that produce the same digest should be computationally infeasible. The tool above computes the digest in your browser using the Web Crypto API; the input never leaves your machine.
The five algorithms this tool emits
| Algorithm | Digest size | Status |
|---|---|---|
| MD5 | 128 bits / 32 hex chars | Broken for collision resistance. Still useful for non-security checksums. |
| SHA-1 | 160 bits / 40 hex chars | Broken for collision resistance (SHAttered, 2017). Avoid for new use. |
| SHA-256 | 256 bits / 64 hex chars | Current default. Used in TLS, signed packages, JWT HS256/RS256. |
| SHA-384 | 384 bits / 96 hex chars | SHA-512 truncated with different initial values. Common in TLS cipher suites and Subresource Integrity (sha384-…). |
| SHA-512 | 512 bits / 128 hex chars | Same family as SHA-256, larger output. Marginally faster than SHA-256 on 64-bit CPUs. |
A sixth mode, Compare hashes, checks whether two pasted digests match (ignoring case) and guesses each one’s algorithm from its length. For dedicated single-algorithm pages, see MD5, SHA-1, SHA-256, SHA-512.
What “broken” means for MD5 and SHA-1
It does not mean “the digest is reversible.” No general-purpose hash inversion exists for any of these algorithms — given a digest, you cannot recover the input.
It means collisions are findable. A collision is two distinct inputs that produce the same digest. For MD5, collisions can be generated in seconds on a laptop. For SHA-1, the SHAttered attack in 2017 demonstrated a practical collision. This breaks any use case that depends on “the digest uniquely identifies the input” — code-signing, certificate fingerprints, anti-tamper checks for software distributions.
It does not break:
- Checksumming for accidental corruption. MD5 catches random bit flips just fine; an attacker doesn’t get to choose the corruption.
- Cache keys, ETags, deduplication. A non-adversarial setting where collision search is irrelevant.
- Old systems that legitimately can’t be upgraded. With caveats.
For anything where an adversary chooses the input, use SHA-256 or better.
What hashes aren’t
- Not encryption. A hash has no inverse; encryption has a key and a decryption operation. Calling SHA-256 “encrypting the password” is a common but real misunderstanding.
- Not a substitute for a password hash. SHA-256 is fast — billions of guesses per second on a GPU. Password storage needs a deliberately slow function: bcrypt, scrypt, or Argon2. Hashing a password with SHA-256 once gives an attacker a free dictionary attack the moment your database leaks. Use a password strength checker to evaluate the password itself, and a real password-hashing library for storage.
- Not a MAC. A hash alone proves the input wasn’t accidentally changed. Proving the input wasn’t intentionally changed by someone who can also rewrite the hash requires a keyed function: HMAC-SHA-256, for example. JWTs use HMAC for exactly this.
- Not a unique fingerprint of meaning. Two semantically-equivalent JSON documents with different whitespace produce different hashes. Canonicalize first if you want content-equivalent inputs to hash equally.
File integrity verification
The classic use: a software vendor publishes the SHA-256 of a release alongside the download. After downloading, you compute the SHA-256 of the file and compare. If they match, the file is bit-exact identical to what the vendor signed.
This protects against accidental corruption (network errors, partial downloads) and against tampering — provided the published hash itself is delivered through a trustworthy channel (HTTPS to the vendor’s site, signed mirror metadata, etc.). A hash on the same compromised page as a malicious download protects nothing.
For files specifically, the file hash verifier hashes file contents directly without you needing to read them in as text first.
Hex encoding
Digests are bytes; the hex form is for human readability. SHA-256’s 32 raw bytes become 64 hex characters. Some tools emit base64 instead — a 32-byte SHA-256 digest is 44 base64 characters or 43 base64url characters without padding. The bytes are the same; the encoding differs. The tool above emits hex.
Algorithm choice cheat sheet
| Use case | Algorithm |
|---|---|
| New code, general security use | SHA-256 |
| Software distribution checksums | SHA-256 |
| HMAC for API request signing | HMAC-SHA-256 |
| Git internal object IDs | SHA-1 (legacy) → SHA-256 (newer Git supports both) |
| Bitcoin / blockchain | SHA-256 |
| Password storage | None of these — use bcrypt / Argon2 |
| Cache keys, ETags | MD5 or SHA-1 are fine |
| Git LFS pointers | SHA-256 |
| TLS certificate fingerprints | SHA-256 (SHA-1 deprecated) |
When in doubt, SHA-256 is the right answer.