SHA-256 reduces any input to a fixed 256-bit fingerprint, written as sixty-four hexadecimal characters. The same input always produces the same digest, and any change at all — one character, one bit — produces a completely different one. It is one-way by design: there is no operation that turns a digest back into the text it came from.
The hashing is done by the browser's own cryptography implementation rather than by code shipped with the page, which means it is the same audited implementation the rest of the platform uses. That API is only available in a secure context, so the tool needs the page to be served over HTTPS.
What SHA-256 is right for
-
It verifies integrity, not identity:
comparing a file's digest against a published one tells you the file was not altered in transit. It says nothing about who produced it unless the digest itself came from a trusted source.
-
It is the wrong tool for storing passwords:
SHA-256 is designed to be fast, which is exactly the property an attacker guessing passwords wants. Password storage needs a deliberately slow function such as bcrypt or Argon2.
-
The digest is fixed length whatever the input:
one character or a gigabyte both produce sixty-four hex characters. Digest length tells you nothing about the size of what was hashed.
-
Identical inputs give identical digests:
which is what makes hashing useful for deduplication and caching, and also why hashing an unsalted value does not conceal it — a common value can simply be looked up.
What a hash actually proves
The [msm_tool slug="sha256-hash-generator"] reduces any input, of any length, to a fixed 256-bit fingerprint written as sixty-four hexadecimal characters. Comparing a downloaded file's digest against one published by its source confirms the file was not altered in transit — it says nothing at all about who actually produced it, unless the published digest itself came from somewhere already trusted.
The wrong tool for storing a password
SHA-256 is built to run as fast as possible, which is exactly the property an attacker testing millions of guesses against a stolen password list wants to find. Password storage needs the opposite property — a function built to be deliberately slow, such as bcrypt or Argon2 — and using a fast general-purpose hash for that job undermines the one thing it is meant to protect.
The output length never changes
One character and an entire gigabyte both produce the same sixty-four hex characters, so the digest's length carries no information whatsoever about the size of whatever was hashed. There is no way to work backwards from a digest to even a rough sense of what went in.
Identical input always means identical output
The same text hashed twice produces the same digest every time, which is exactly what makes hashing useful for deduplication and caching — matching digests mean matching content without comparing the content itself. It is also why hashing a value on its own does not conceal it: a common password or a predictable string produces a digest that can simply be looked up against a precomputed list, which is the reason password hashing needs a salt and a slow function rather than a bare digest.
Computed in the browser, over HTTPS only
The hashing runs through the browser's own cryptography implementation rather than code shipped with the page, which means it is the same audited routine used elsewhere on the platform. That implementation is only exposed in a secure context, so the page has to be served over HTTPS for it to be available at all.
Against MD5
MD5 is broken in a way that matters in practice: two different inputs can be deliberately constructed to produce the same digest, which defeats the entire point of using one to verify integrity. SHA-256 has no equivalent practical weakness, which is the reason to reach for it instead wherever a choice is available.