Hash Generator — SHA-1, SHA-256, SHA-384, SHA-512

Hashing is not encryption

A hash looks like it ought to be reversible — a short input becomes a long string of hex — so people routinely assume it can be decrypted. It cannot. Hashing is one-way by design: there is no key, and no decryption function exists to write. If someone asks you to decrypt a hash, the honest answer is that the operation does not exist.

What attackers actually do is guess. They hash enormous numbers of candidate inputs and compare the results against a stolen digest. This is why a short or predictable input offers no protection at all — the SHA-256 of a common password or a phone number is effectively public knowledge, already sitting precomputed in lookup tables. Hashing a secret does not conceal it; it conceals it only to the extent the secret was unguessable in the first place.

Do not use these algorithms for password storage

The SHA family is fast, and commodity GPU hardware pushes it into the billions of hashes per second. For verifying a file that speed is exactly what you want. For passwords it is precisely wrong: a stolen database hashed with plain SHA-256 can be attacked at billions of guesses per second, which turns most real passwords into a matter of hours.

Password storage needs an algorithm that is deliberately slow and tunable — bcrypt, scrypt or Argon2, each with a cost factor you raise as hardware improves. A unique per-user salt is what defeats precomputed tables, since it means the attacker cannot reuse any work between accounts. To be blunt about it: a plain SHA hash of a password is not adequate, salted or not, because the problem is the speed rather than the salt.

SHA-1 is offered, but not for anything new

SHA-1 is included because a great many existing systems still publish SHA-1 checksums that people legitimately need to verify — older software distributions, legacy archives, established package manifests. Removing it would break a real use case.

It should not be chosen for anything new. A practical collision has been publicly demonstrated, which means an attacker can construct two different inputs sharing one digest, so SHA-1 no longer provides the guarantee that a matching hash implies a matching file. Use it to check a legacy value you have been handed; use SHA-256 for everything you control.

Integrity verification — the genuine use

The real workflow is simple. A project publishes the SHA-256 of a release; you hash the file you actually received and compare. If the values differ, what you have is not what they published — whether through corruption in transit or interference.

Note carefully what that does and does not prove. It establishes that your copy matches the published digest, so the protection is only as good as your confidence in the digest itself. A digest served from the same compromised page as the download proves very little, which is why projects publish checksums over HTTPS, on a separate host, or signed.

Everything runs locally through the browser's own crypto.subtle.digest, so nothing you paste is transmitted. Web Crypto requires a secure context, meaning the page must be served over HTTPS to work at all. When comparing two digests, check the whole string rather than the first few characters — a matching prefix is easy to arrange and means nothing on its own.

Hashing text and hashing a file are the same operation on different inputs, and the results differ more often than people expect — usually over a trailing newline. The file hash tool handles the file case.