What a hash is good for
A cryptographic hash reduces input of any size to a short fixed-length value, with two properties that make it useful. Any change to the input, however small, produces a completely different output. And it is computationally infeasible to construct a second input producing the same output.
Together those give you a way to answer one narrow question precisely: is this content identical to that content? Matching hashes mean nothing changed. Different hashes mean something did, even if you cannot see what.
This is why hashes appear wherever integrity matters — verifying a download completed intact, confirming a file was not altered in transit, deduplicating storage, and detecting whether a configuration changed between deployments.
Choosing an algorithm
SHA-256 is the right default for essentially everything. It underpins TLS certificates, code signing, and most blockchain systems, and it has no known practical weaknesses. Unless something specifies otherwise, use it.
SHA-384 and SHA-512 produce longer digests and are appropriate where a standard or a compliance requirement asks for them. They are not meaningfully more secure for ordinary use, and on 64-bit hardware SHA-512 is often faster than SHA-256 despite the longer output.
SHA-1 is offered here only because legacy systems still emit it and you sometimes need to match one. Practical collisions were demonstrated in 2017, and it should never be chosen for anything new. MD5 is absent entirely: browsers do not implement it, having been broken for collision resistance since 2004.
Why hashing a password is not enough
A general-purpose hash is designed to be fast, and speed is exactly wrong for passwords. An attacker with a database of hashes can try billions of candidates per second on ordinary hardware, and most passwords fall to a dictionary long before brute force becomes necessary.
Two things fix this. A salt — random data unique to each password — means identical passwords produce different hashes, defeating precomputed lookup tables. And a deliberately slow algorithm such as bcrypt, scrypt or Argon2 makes each attempt expensive enough that large-scale guessing stops being practical.
So the tools on this page are the wrong ones for password storage, and it is worth being explicit about that rather than leaving it implied. They are for integrity checking, which is a different job.
What a matching checksum does and does not prove
It proves integrity: the content is byte-for-byte identical to whatever produced the reference hash. That is genuinely valuable — it catches truncated downloads, corrupted transfers and altered files.
It does not prove authenticity. A hash says nothing about who produced the content, only that it has not changed since. If an attacker can alter the file, they can usually alter the published hash alongside it, which is why the reference value has to come from a source and a channel you trust independently.
This is the reasoning behind signed releases: a signature ties the hash to an identity, which a bare checksum on the same page as the download does not.