A file hash is a value computed from a file's contents using a specified algorithm. It is useful for comparing bytes across copies, checking a download against a published reference, and identifying whether content has changed. It does not explain what the file will do when opened.
Two questions therefore need different evidence: “Does this file match the reference?” and “Should this reference be trusted?” A hash comparison addresses the first question. It cannot supply the second answer on its own.
The algorithm is part of the value
A digest without an algorithm name is an incomplete comparison. SHA-256 and SHA-512, for example, produce different outputs from the same input. A reference identified as SHA-256 must be compared with a SHA-256 result, not with whichever value a tool happens to show first.
NIST's cryptographic-hash definitions describe a fixed-length output derived from input bits and the security properties expected of cryptographic hash functions. Fixed length does not mean every possible file has a mathematically unique digest. Different inputs can map to the same output; a secure design aims to make finding such collisions computationally infeasible.
That distinction matters when writing a precise conclusion. A strong matching digest is practical evidence of matching content in an appropriate comparison. It is not a proof that collisions are logically impossible.
A renamed file can have the same hash
Ordinary file-content hashing processes the bytes inside the file, not its name in the directory. Rename a file without changing those bytes and its content digest remains the same. Two files with different names can therefore match.
Microsoft's Get-FileHash documentation explicitly distinguishes file content from filenames and extensions. Our file-extension explanation covers the related reason that renaming an extension does not convert the underlying format.
The reverse also holds: two files called report.pdf can contain different bytes. A familiar name is not evidence that a received document is the same version as a previously approved one. The comparison needs the actual contents.
Visually identical does not mean byte-identical
A document can look unchanged while its internal metadata, compression, or editing history differs. A text file can contain a different line-ending convention without an obvious change in a normal editor. Those byte differences can produce different cryptographic digests.
Embedded metadata is part of the file's content when it is stored inside the file. Filesystem information stored separately, such as an ordinary directory timestamp, is not automatically included by a tool that hashes only file contents. Read the tool's scope rather than treating every visible property as part of the digest.
This explains why a hash mismatch is evidence of a content difference, not a diagnosis of malicious alteration. Re-exporting a legitimate document can change its bytes. A truncated download can also change them. The digest identifies the mismatch; further investigation explains it.
Compare the correct object
A compressed archive and a file extracted from it are different byte sequences. The archive's published digest should be compared with the downloaded archive. Hashing an extracted document instead does not test the same object.
Our compression-and-encryption guide explains why packaging, reducing size, and protecting confidentiality are separate functions. An encrypted copy likewise has a different representation from the readable original. Use the reference for the exact artifact and version.
When several downloads exist for different operating systems or processor types, match the reference to the selected download. A valid digest for the wrong package is still the wrong comparison. Record the version and platform along with the algorithm and expected value.
The reference needs a trustworthy origin
Suppose a malicious file is accompanied by its correctly computed hash on the same untrusted page. The two will match. That agreement shows consistency between the file and the page; it does not make the file harmless or connect it to the publisher the page claims to represent.
Obtain reference information through the publisher's legitimate distribution route and follow its verification instructions. A digital signature, where provided, serves a related but different purpose by adding cryptographic evidence tied to a signing key. Evaluating the key or certificate's identity and trust remains part of that process.
The HTTPS and seller-legitimacy article makes a parallel distinction. A protected connection can deliver misleading content intact. Security evidence must be matched to the claim it actually supports.
Hashing is not encryption or a malware scan
A hash is not a recoverable encrypted copy of the original file. It does not preserve enough information to reconstruct arbitrary input. It also does not inspect the file's behavior, validate its business purpose, or establish that opening it is appropriate.
Security products may use hashes as one signal, but calculating a digest yourself is not equivalent to a complete security assessment. A new or altered harmful file still has a perfectly valid hash value.
Microsoft's documentation also warns that older algorithms such as MD5 and SHA-1 are unsuitable where resistance to deliberate tampering is needed. Follow the publisher's current supported verification method rather than choosing an algorithm because its output is shorter.
State the result narrowly
A useful record says which file, which version, which algorithm, and which reference were compared. “The SHA-256 digest matches the publisher's reference for this package” is more informative than “the file is verified” without qualification.
If it does not match, do not silently accept the file because its name and size look plausible. Recheck the intended version and verification method, then use the publisher's support or download process. The result has done its job by exposing a difference that the filename could not show.
Sources
- NIST: Cryptographic Hash Function
Cryptographic hashes map input bits to a fixed-length output and are designed for collision and preimage resistance; fixed-length digests do not make collisions mathematically impossible.
- Microsoft: Get-FileHash
The command hashes file contents with a selected algorithm; changing a filename does not change the content hash. Weak algorithms are not suitable for tampering resistance.