What a hash actually is
A cryptographic hash function takes any input, from a single letter to a gigabyte of logs, and produces a fixed-length fingerprint called a digest. SHA-256 always produces 256 bits (64 hex characters), SHA-1 produces 160 bits (40 characters) and SHA-512 produces 512 bits (128 characters). The same input always gives the same digest, and a good hash function is one way: there is no method for turning a digest back into the text that produced it.
The other defining property is the avalanche effect. Change one character of the input, even just its case, and roughly half the bits of the output flip, so the new digest looks completely unrelated to the old one. That is what makes hashes useful for spotting tampering: if a file's published SHA-256 matches the one you compute after downloading, the file arrived intact.
Everything on this page runs in your browser through the WebCrypto API. Nothing you type is uploaded, so it is safe to hash tokens, keys and anything else you would not paste into a random website.
See the avalanche effect yourself
Both "hello" digests are the same length, yet they share nothing you could spot by eye. The empty-string digest is worth recognising: it turns up in logs and databases whenever something hashed a blank value by mistake.
Why there is no MD5 button
MD5 is deliberately missing. Researchers demonstrated in 2004 that you can manufacture two different inputs with the same MD5 digest, and the attacks have only become cheaper since: a collision now takes seconds on a laptop. A hash you can forge collisions for cannot prove integrity, which is the one job a hash has. Browsers reflect this, and the WebCrypto API that powers this tool does not implement MD5 at all.
SHA-1 sits in an awkward middle ground. Google and CWI Amsterdam published a practical collision in 2017 (the SHAttered attack), so it should not secure anything new either. It is included here because a huge amount of existing tooling still displays SHA-1 values, from git commit ids to legacy download checksums, and you often need to reproduce one to compare against.
Which algorithm should you pick?
For anything current, use SHA-256. It is the default here, it is what most download pages publish, and it is the workhorse behind TLS certificates, code signing and Bitcoin. SHA-512 offers a longer digest and is slightly faster on some 64-bit hardware; pick it when a spec asks for it. Reserve SHA-1 for matching values produced by older systems.
One common misuse is worth flagging: none of these are password-storage algorithms. They are designed to be fast, and fast is exactly wrong for passwords, because attackers with a stolen database can test billions of guesses per second. Password storage belongs to slow, salted schemes such as bcrypt, scrypt or Argon2. Use the hashes on this page for fingerprints, checksums, cache keys and integrity checks, and let them do what they are genuinely brilliant at.
Frequently asked questions
Is my text uploaded anywhere?
No. Hashing runs entirely in your browser using the WebCrypto API built into every modern browser. Nothing you type is sent to a server, which makes the tool safe to use with tokens, keys and anything else you would rather keep private.
Why is there no MD5 option?
MD5 has been broken since 2004: researchers can manufacture two different inputs that share the same MD5 hash, which defeats the whole point of a hash. Browsers agree, so the WebCrypto API does not even implement it. If a system forces you to use MD5, treat that as a sign the system needs updating.
Can I reverse a hash back to the original text?
Not directly. Hash functions are one way, so there is no formula that turns a digest back into its input. The caveat is short or common inputs: attackers can hash millions of guesses and compare, which is why single dictionary words make weak passwords no matter how strong the hash is.
Should I use SHA-1 for anything new?
No. Practical collision attacks against SHA-1 were demonstrated in 2017, and browsers and certificate authorities have dropped it. It is included here because plenty of older systems, checksums and git repositories still show SHA-1 values you may need to reproduce or compare.
Is SHA-256 the right way to store passwords?
No. Plain SHA-256 is deliberately fast, which lets attackers test billions of guesses per second against stolen hashes. Password storage needs a slow, salted algorithm designed for the job, such as bcrypt, scrypt or Argon2. Use SHA-256 for integrity checks and fingerprints, not for passwords.