SHA-1 vs SHA-256 vs SHA-512: Which Hash Should You Use?
A hash turns any input into a fixed-length fingerprint. The same input always gives the same output, a one-character change gives a completely different one, and the process cannot be reversed. The Hash Generator produces SHA-1, SHA-256, SHA-384 and SHA-512 from any text.
What a hash is actually for
Three jobs. Verifying a download - the publisher states the hash, you compute it on the file you received, and if they differ the file is not what was published. Detecting change - store the hash of a record and you can tell later whether anything altered, without keeping a copy. Comparing without revealing - two parties can confirm they hold the same value by exchanging hashes rather than the value itself.
What it is not for is secrecy of the input alone. A hash of a short, predictable value can be cracked by hashing every candidate until one matches, which is exactly how leaked password tables get reversed.
SHA-1 is broken
Not weakened - broken. A practical collision was demonstrated in 2017: two different files producing the identical SHA-1 hash. That defeats the entire purpose, because a hash is only a fingerprint if different inputs give different outputs.
Do not use SHA-1 for anything security-related. It survives in old systems and in Git, where it is used for addressing rather than security. For a new signature, certificate or integrity check, it is unacceptable.
SHA-256 is the default, and SHA-512 is not simply better
SHA-256 is the right answer for almost everything. It is thoroughly analysed, universally supported and has no known practical weakness.
SHA-512 produces a longer digest but is not meaningfully more secure for any realistic threat - SHA-256 is already far beyond brute force. What it sometimes is, counter-intuitively, is faster: it works on 64-bit words, so on a 64-bit processor it can outrun SHA-256 on large inputs. Pick it for that reason or because a specification demands it, not because the number is bigger.
None of these suits passwords
This is the mistake that matters most. SHA hashes are designed to be fast, and fast is exactly wrong for a password, because speed helps the attacker guessing billions of candidates a second.
Passwords need a deliberately slow algorithm with a per-user salt - bcrypt, scrypt or Argon2. If you are choosing between SHA variants for a password column, the answer is none of them. Start with a strong password from the Password Generator and store it with something built for the job.
Common questions
Can a hash be reversed?
Not mathematically. But a short or common input can be found by guessing, which is why hashing alone does not protect a password.
Will the same text always give the same hash?
Always, on every machine and in every language. That is what makes verification possible.
What is a salt?
A random value added to each input before hashing, so identical passwords produce different hashes and one precomputed table cannot crack them all.
Is MD5 still usable?
Only as a non-security checksum, and SHA-256 is better even there. It has been broken far longer than SHA-1.
Need a hash of something?