Hashes, IDs, and randomness
Does a downloaded file match the published hash?
Tools to use
A completed download with the expected filename can still leave a question: is this the correct, intact version? The long hexadecimal string on a release page helps answer it. A digest is calculated from content, so it compares actual bytes rather than filenames or timestamps. Where you obtained the expected digest matters just as much as the comparison itself.
Start with abc to check the comparison procedure
Open SHA hashing, enter lowercase abc without a trailing space or newline, select SHA-256 and hexadecimal output. The result should match these 64 characters. Each hexadecimal digit represents four bits, so a 256-bit digest has 64 digits regardless of the file's size.
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015adSwitching to SHA-512 computes a different digest. Switching only to Base64 represents the same digest bytes differently. Match the algorithm and output representation before comparing; a SHA-256 value differing from SHA-512 does not demonstrate a failed download.
Why visually identical text can differ
Add one LF newline after abc. A single additional byte produces a very different-looking digest because hashing processes bytes, not textual meaning or appearance. An editor inserting a final newline or an accidental copied space has the same consequence. Similar-looking digest prefixes do not measure how much content changed.
edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cbEncoding also matters: the same visible characters have different UTF-8 and UTF-16 bytes. Text input is hashed as UTF-8, while file selection uses the file's actual bytes. Re-encoding or changing line endings before comparison stops testing the original download. Select the untouched file before opening and resaving it.
A reliable order for checking a download
First identify the release version, OS, CPU variant, filename and hash algorithm on the official distribution page. Hash the saved file with that algorithm and compare the entire value, not just a prefix. A ZIP archive and its extracted executable, different platforms, or different releases sharing a filename are distinct byte sequences.
If values differ, recheck the target and algorithm. An incomplete download or modification is possible, but the digest alone cannot diagnose the cause. Review the trusted download path instead of executing the file to investigate. For files exceeding the tool's limit, use a suitable local utility; hashing a fragment is not hashing the original file.
A match does not establish who published the file
A file and digest obtained from the same untrusted page can agree perfectly. Anyone changing the content can calculate a new digest. Hash comparison is useful when the expected value comes through a trusted path. It has a different role from authenticating the official HTTPS site or checking a publisher's digital signature.
Matching also does not mean safe software: an authentic release can contain vulnerabilities. Conversely, a mismatch is not automatically an attack; another version or changed newlines also differs. Interpret the result as a content comparison without jumping to a safety verdict or a diagnosis.
Choose the right role for hashing, CRC and encryption
CRC32 can detect data differences, but is not designed to resist deliberate adversarial modification. If the publisher specifies SHA-256, use that algorithm rather than substituting CRC32. A hash is not reversible encryption either. Nor does plain SHA-256 alone constitute an appropriate password-storage design; that is a separate problem from file verification.
For a repeatable check, record the filename and version, algorithm, source of the expected value and match result, without sharing confidential file contents. Calculation runs in the browser, but shared devices and clipboards still need care. A useful conclusion states what was compared, against which trusted reference, and with which algorithm.
Where did the expected digest come from?
Matching a downloaded file against a digest from the same location checks that its bytes correspond to that value. If both file and digest were replaced, agreement is not proof of safety. Digest comparison and trust in the expected value are separate. Do not replace a publisher's required signature-verification process with a hash check and claim equivalence; this tool does not authenticate provenance or signers.
Align algorithm and output format first: hexadecimal SHA-256 and Base64 of the same digest are different strings. Pasting a file into a text field can change encoding or line endings, so use raw file input for file verification. Separate the digest from any filename or formatting, and compare the full value rather than a short matching prefix.
A mismatch may come from a different version, incomplete download, archive versus extracted file or newline conversion; it does not by itself prove an attack. Nor should an unexplained mismatch be dismissed as 'close enough.' Record version, filename, byte count, algorithm and both digests. A hash detects difference but does not diagnose its cause.