Make a comparison that can detect the intended change

A SHA-256 comparison is meaningful when you hash the same representation on both sides. Text with an extra line break or a different character encoding can produce another digest even when it looks identical. A file hash normally refers to the complete file bytes; copying visible text out of a PDF and hashing that text does not reproduce the PDF file's checksum.

Obtain the expected digest from a source you trust, then compare the complete value rather than only a few starting characters. If an attacker can replace both a download and its published checksum, matching values do not establish authenticity. A mismatch tells you the inputs differ but does not explain whether the cause is damage, a version change or altered metadata. Keep the filename, version and expected digest together when recording the check, and do not treat an ordinary hash as a way to securely store a password.

Hashes are fingerprints, not encryption

Encryption is meant to be reversed with the right key. A hash is not. It is designed to make a repeatable fingerprint from the input so you can compare values later.

Changing even one character changes the hash, which is why hashes are useful for spotting whether text was altered.

Use SHA-256 for modern checks

SHA-256 is widely used for checksums, integrity checks, API workflows, and technical records. Older hashes such as MD5 and SHA-1 can still appear in legacy systems, but they should not be treated as strong security choices for new work.

If a website or vendor publishes a checksum, generate the same hash from your copy and compare the two values exactly.

Keep sensitive input local

For API examples, configuration snippets, identifiers, or private text, local browser hashing avoids sending the input to a server just to calculate the result.

Do not hash passwords in a simple public webpage and treat that as password storage. Secure password storage requires salts, slow password-hashing functions, and server-side controls.