Try it: Follow the SHA-256 verification walkthrough ↗
The same bytes produce the same hash
A cryptographic hash function reads all of the input and produces a fixed-length value. If two files are byte-for-byte identical, they produce the same result under the same algorithm. Change even a tiny part of the file and the calculated value will normally be completely different.
That property makes hashes useful for integrity checks. Software publishers often provide a checksum next to a download. You calculate the checksum of your local copy and compare the two values character by character.
SHA-256 is a common modern choice
SHA-256 produces a 256-bit digest and remains widely used for file integrity. MD5 and SHA-1 are older algorithms with known collision weaknesses, which means an attacker can deliberately construct different inputs that share the same hash under certain conditions. They can still appear in legacy workflows, but they are not a good choice when collision resistance is important.
For ordinary download verification, use the algorithm specified by the trusted publisher. If multiple hashes are offered, SHA-256 or a stronger modern option is preferable to MD5.
The expected hash must come from somewhere you trust
A calculated SHA-256 value is only useful when you have a reference value to compare with it. If an attacker can replace both the download and the checksum displayed beside it, the comparison tells you very little. For high-assurance workflows, obtain the expected value from a trusted signed release, package manager or independent channel.
For your own files, recording a hash at a known-good point can help you detect later changes. Keep the reference value separately from the file when tamper detection matters.
A matching checksum is not a malware verdict
A hash comparison answers whether the bytes match the reference. It does not tell you whether those bytes are benign, legal, authentic or appropriate to run. If the original publisher distributed malicious software, a perfect checksum match simply confirms that you downloaded the same malicious software.
Use endpoint security, code-signing verification and source reputation as separate checks when evaluating executable files.
A practical verification workflow
- Download the file from the intended publisher.
- Copy the published SHA-256 value from a trusted source.
- Calculate the SHA-256 of the local file.
- Compare the complete values, not only the first few characters.
- If they differ, do not assume the file is “close enough”; obtain a fresh trusted copy.
Keep the original and verify the result
File conversion is most reliable when the source is preserved until the new file has been checked in its real destination. If a document, image, subtitle or media file has legal, archival or production value, keep the original separately and treat the converted version as a derivative copy.
Worked example: compare two release files
| Step | Example | Interpretation |
|---|---|---|
| Compute checksum | SHA-256 of downloaded release.zip | A fingerprint of the exact downloaded bytes. |
| Obtain expected hash | Copy the complete value from a trusted publisher source | A value pasted from the same untrusted mirror adds little assurance. |
| Compare | Exact character-by-character match | Strong evidence of byte-for-byte agreement. |
| Mismatch | Even one hexadecimal character differs | Investigate incomplete downloads, alternate versions or modification. |
For short text, SHA-256 values can also be checked with established command-line tools such as shasum -a 256 filename on macOS or sha256sum filename on many Linux systems. Compare the full digest, not just a few leading characters.