SHA-256 Hashing Explained in Plain English
What a cryptographic hash can prove, what it cannot, and why hashing is different from encryption and password storage.
Think of a hash as a fingerprint
A hash function turns arbitrary input into a fixed-length digest. Identical bytes produce identical hashes; a tiny change produces a dramatically different digest.
Hashing is one-way, but guesses are still possible
There is no normal decode operation. However, if an input is predictable—such as a common password—an attacker can guess it, hash the guess and compare.
Checksums need a trusted expected value
If a software publisher provides a SHA-256 checksum over HTTPS, you can hash your downloaded file and compare. If an attacker can replace both the file and the published checksum, the comparison provides no authenticity.
Passwords need dedicated algorithms
Fast SHA-256 is excellent for many integrity uses but deliberately too fast for password storage. Password systems use salted, slow algorithms such as Argon2, scrypt or bcrypt to make guessing expensive.
SHA-1 is legacy for collision resistance
New designs should generally avoid SHA-1 when collision resistance matters. Modern SHA-2 family choices such as SHA-256 are widely used.
A task you can work through
Hash the exact text “invoice-v1” with SHA-256, then change the last character to make “invoice-v2”. Compare the two hexadecimal digests: their length stays the same while the values change. That is useful for checking whether two exact byte sequences match. A file integrity workflow would hash the file bytes before transfer and after receipt; this site’s Hash Generator accepts text, so it is not a file checksum tool.
Where this approach fails
A hash is not encryption; there is no secret key and no decryption step. Hashing a predictable password with plain SHA-256 is not an adequate password-storage design; a dedicated password hashing function with salt and work factor is needed. Matching hashes provide strong evidence of identical input bytes, but mismatched hashes do not explain where a change occurred. Encoding, whitespace and letter case matter: “Hello” and “hello” are different inputs.
Check the result before using it
To reproduce a digest elsewhere, agree on the exact algorithm, UTF-8 encoding and whether a trailing newline is present. Copy the entire digest, not the first few characters, when comparing. If you need to verify a downloaded binary file, use a local file-hashing utility instead of pasting a filename into this text-only tool.
Understand the boundary of an integrity check
Suppose a publisher posts a SHA-256 digest beside a download. You compute the digest of the downloaded bytes with a trusted local tool and compare every hexadecimal character. A match supports that the bytes are the same as those represented by that digest. It does not prove the publisher was trustworthy if an attacker could replace both the file and the published digest. The text tool on this site hashes typed text, so choose a file-hashing utility for downloaded binary files.
Try the related tool
Generate SHA-1/256/384/512 hashes. The tool page explains its implementation and limitations. Keep your original and inspect any important result.
Hash Generator →Technical references
These external references explain the underlying formats or browser APIs. The worked examples above describe this site's specific tool behavior.