Hash Generator
SHA-1, SHA-256, SHA-384 and SHA-512 over text or a dropped file.
What a hash is for
A cryptographic hash turns any amount of input into a fixed-size digest, such that finding two inputs with the same digest is computationally infeasible. That single property underpins a lot of everyday work: verifying a download arrived intact, detecting whether a file changed, deduplicating content, and building the Merkle structures that Git and every blockchain depend on.
Verifying a download without uploading it
This is the case where a browser-based tool genuinely beats the alternatives. A project publishes the SHA-256 of its installer; you want to check the file you just downloaded matches. Uploading a 400MB installer to a website to find that out is absurd — and on a corporate network, often prohibited.
Drop the file on the panel above instead. It is read with the File API and hashed in memory by the Web Crypto API. Nothing is transmitted, and the file never leaves your disk in any meaningful sense. Paste the published checksum into the verify field and the comparison is done for you — in constant time, and case-insensitively, because published checksums are inconsistently cased and eyeballing 64 hex characters is how mismatches get missed.
Why there is no MD5 here
The Web Crypto API deliberately does not implement MD5, and shipping a hand-written one would invite exactly the misuse that omission is meant to prevent. MD5 has been broken for collision resistance since 2004 — colliding files can be produced on a laptop in seconds. SHA-1 is included because Git and older systems still emit it, but it is in the same category: fine as a non-security checksum, unacceptable as a signature. For anything new, use SHA-256.
Hashing is not password storage
This is the most consequential misunderstanding about hashes. SHA-256 is designed to be fast — billions of operations per second on commodity GPU hardware. That is a virtue when you are checksumming a file and a catastrophe when you are storing a password, because the attacker gets that same speed.
Password storage needs a deliberately slow, salted key-derivation function: Argon2id, scrypt or bcrypt. They are tunable so that a single verification takes a noticeable fraction of a second, which is invisible to your user and ruinous to someone working through a leaked table. A salted SHA-256 is still the wrong tool; the salt stops precomputed rainbow tables and does nothing about raw speed.
A hash proves two things are the same. It does not keep anything secret.