Hash Generator

SHA-1, SHA-256, SHA-384 and SHA-512 over text or a dropped file.

Input
Digests
Verify against a known checksum
Send output to

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.

Questions people actually ask

Can I hash a file without uploading it?
Yes. Drop a file on the input and it is read with the File API and hashed in memory. Nothing is sent anywhere, which makes this a safe way to verify a download's checksum.
Why is MD5 not offered?
The Web Crypto API deliberately omits MD5 because it is broken for anything security-related, and shipping a hand-rolled implementation would invite exactly the misuse the omission is meant to prevent.
Can I use this to hash passwords for storage?
No, and neither can any plain SHA function. Password storage needs a slow, salted KDF such as Argon2id, scrypt or bcrypt. A raw SHA-256 of a password is cracked at billions of guesses per second.
navigate open esc close