Hash Calculator
Get MD5, SHA-1, SHA-256 and SHA-512 in one pass. Text and files both work, entirely on this page — not a single byte of your file is uploaded. If all you need is "did it arrive intact", CRC32 checksum is faster.
| MD5 | — | |
| SHA-1 | — | |
| SHA-256 | — | |
| SHA-512 | — |
—
A hash is not encryption
Encryption is reversible; a hash is not. Whatever the input length, the output is fixed-length, and the original cannot be recovered from it. That makes it right for integrity checks and fingerprints, and wrong for hiding content — use real encryption for that. And because it is one-way, it should not be used to store passwords: a GPU computes billions of SHA-256 per second. Password storage needs a deliberately slow hash (bcrypt / scrypt / Argon2).
Are MD5 and SHA-1 still usable?
Depends what you are defending against. Against "the file got corrupted in transit", both are fine and fast. Against "someone deliberately changed it", neither works — practical MD5 collisions date to 2004 and SHA-1 was broken in 2017. They are shown next to SHA-256 / SHA-512 so you can compare against values already in old systems, not as a recommendation. New work: use SHA-256.
It hashes bytes
The same Chinese text encoded as UTF-8 or GBK produces completely different bytes, and therefore different digests. This page always uses UTF-8, so a mismatch against a value computed under GBK is expected. Files do not have this problem.
Questions
Because the SHA family uses the browser’s crypto.subtle, which is only available in a secure context (HTTPS or localhost). That is a browser rule, not a limit of this page. MD5 is implemented here and is unaffected — so in such an environment you will see a value for MD5 and dashes for the other three.
No. The browser reads it locally (File.arrayBuffer()) and the digest is computed on this page with no network requests. It works offline.
128 MB, for the same reason as the CRC32 page: the whole file has to fit in memory. For bigger files use sha256sum or certutil -hashfile, which can stream.
Most likely a different encoding: the other side may have used GBK or UTF-16. Next most likely: a trailing newline. Start with short ASCII input such as abc — it should give 900150983cd24fb0d6963f7d28e17f72. If that matches, both algorithms are fine and the difference is in the input bytes.
