SHA-256 hash generator

SHA-256 has no known practical collision, no length-extension problem in the ways people usually use it, and hardware acceleration on essentially every processor made in the last decade. It is what certificates are signed with, what Subresource Integrity puts in a `integrity` attribute, what a package lockfile records, and what Bitcoin is built on.

None of that is an argument from popularity. It is an argument from scrutiny: an algorithm this widely deployed has had more attention paid to breaking it than any alternative, and it has held. Choosing something less common to be clever is how people end up with a primitive nobody has audited.

The digest here comes from `crypto.subtle`, the browser own cryptography, which is implemented in the same native code that verifies certificates. The MD5 page is the exception on this site: it is written out, because the Web Crypto standard deliberately does not offer MD5.

That distinction is worth stating rather than glossing. A hash function implemented in JavaScript can be correct, and this site tests its one such implementation against RFC 1321 — but for anything that still has security properties, the right answer is the one the platform already ships and keeps patched.

There is no key and nothing to reverse. A digest is a fingerprint: the same input always produces it, and a different input almost certainly does not. You cannot get the input back, and you also cannot hide the input by hashing it — anything guessable can simply be hashed by the attacker and compared.

This is the mistake behind a great many hashed email addresses and hashed phone numbers treated as anonymised data. There are only so many phone numbers; hashing all of them takes minutes. A hash anonymises nothing that comes from a small or enumerable set.

Passwords, again and for the same reason as MD5: it is fast. Hardware acceleration makes it faster still, which is excellent for verifying a certificate and precisely wrong for resisting a guessing attack. Password storage wants bcrypt, scrypt or Argon2, all of which are deliberately slow and tunable.

Message authentication is the other one. Hashing a secret together with a message is a pattern with real pitfalls, and HMAC exists to avoid them — it is the construction to use, and `crypto.subtle` provides it. A plain digest of "key plus message" is a well-known way to get this wrong.

Encoding first. This hashes UTF-8 bytes, and a system that stored the same text in another encoding produces a different digest for what looks like the same string. A trailing newline second — a file usually ends with one and a text box does not, which is enough to change every character of the result.

Both are worth checking before concluding that something is wrong, because a hash gives no partial credit. Two digests either match or share nothing, so there is no gradient to tell you that you are nearly right, and every near miss looks exactly like a total mismatch.

SHA-256 is sixty-four hexadecimal characters, always, whatever the input. MD5 is thirty-two, SHA-1 is forty, SHA-512 is a hundred and twenty-eight. Counting the characters of a digest somebody handed you is the fastest way to find out which algorithm it came from when the documentation does not say.

It is also a quick check on a stored column. A field that is meant to hold SHA-256 and contains forty characters is holding SHA-1, and it is holding it because something upstream was never updated — which is a more common finding than it ought to be.