Download Hash Checks: Match the File and the Reference

Use a harmless text-file exercise to understand SHA-256, choose the right publisher reference and keep a matching hash separate from an installation decision.

Original navy and gold illustration of a laptop showing a document and five fingerprint tiles, a separate card with matching tiles, and a magnifying glass

A matching download name does not tell you whether two files contain the same bytes. A SHA-256 comparison gives you a more precise check: calculate a value for the file, identify the right published reference and compare the complete values. Keep a separate record of where that reference came from.

This guide uses a harmless text-file exercise and a fictional download worksheet. It does not certify any i8 Live download, recommend an installer or describe a file we have inspected for you.

Start with the question the check can answer

Imagine that you saved two copies of a reading-club timetable. Both are named timetable.txt, but they came from different folders. Before asking which copy to open, you want to establish whether their contents match.

Microsoft documents Get-FileHash as a tool that computes a file-content hash. Renaming a file or changing its extension does not change that content-based result. Editing the contents can change the result even when the displayed filename stays the same.

NIST describes a cryptographic hash as a fixed-length representation of an input, with properties designed to make finding collisions computationally infeasible. That supports using a suitable hash for a content comparison. It does not turn the hash into a description of what the file does.

For our worksheet, the question is deliberately narrow: does this local file's SHA-256 value match the reference for this exact release? Questions about who published the release and whether you should use it need their own evidence.

Pair the reference with the exact file

Before calculating anything, record the publisher page, release version and exact asset name. A release page may list separate files for different operating systems or processor architectures. Select the row belonging to the file you actually downloaded.

A useful reference record contains:

  • The publisher page URL you checked.
  • The release version and asset filename on that page.
  • The algorithm label beside the published value.
  • The complete published value and the date you checked it.

Copying a value from an unexplained chat message leaves the reference's origin unresolved. A person who supplies a file can also supply a matching hash for that file. Agreement with that message alone cannot establish that it came from the intended publisher.

If the publisher does not provide the expected algorithm or an unambiguous file-to-value pairing, mark the reference unavailable. A locally calculated value can still label your copy for later comparison. It cannot fill in a missing publisher reference.

Practise on a text file you create yourself

Use a small text file that you created, rather than an unfamiliar downloaded program. In this example, save three ordinary words in a file named practice-notes.txt. Record the actual folder containing it; the example path below is only suitable if you placed your file there.

Microsoft's PowerShell documentation supports explicitly selecting SHA256 and using LiteralPath for the exact file path. In PowerShell, our example calculation is Get-FileHash -Algorithm SHA256 -LiteralPath 'C:\Downloads\practice-notes.txt'. Substitute your own existing text-file path before running the calculation.

Read the returned Algorithm, Hash and Path fields together. The Path tells you which local file was measured, while the algorithm identifies the kind of value being compared. A result for another copy in another folder does not answer the question about your intended file.

The calculation reads the file to produce a hash; it does not require launching that file as a program. Our practice exercise only needs a text file you already understand. If you are unfamiliar with PowerShell, review Microsoft's linked command documentation before using the example.

Change one thing at a time

Keep the experiment small enough to trace each result. Use this sequence before comparing the observations below.

  1. Save the first hash together with its local file path.
  2. Rename the file without editing it, update the command path and calculate a second hash.
  3. Change one word, save the file and calculate a third hash.
Practice actionWhat to compare
Rename the unchanged fileFirst and second complete hashes
Edit a word and saveSecond and third complete hashes
Select a different folder copyPath as well as the hash

This exercise separates a file's label from the bytes being measured. The rename comparison should preserve the content hash when the contents remain unchanged. The editing comparison demonstrates why an unchanged filename is insufficient evidence of unchanged contents.

If your observations differ from the intended exercise, check which file was selected and whether an editor saved a different copy. Preserve the observed values rather than inventing a result. You are investigating a local sequence, not proving that a particular downloaded file is trustworthy.

Compare complete values under the same algorithm

Return to a real download only after you have a clear reference record. Calculate SHA-256 for the downloaded file and compare it with the publisher's SHA-256 entry for that exact asset. Do not compare a SHA-256 result against a value labelled with a different algorithm.

Compare every character of the actual hash value. Matching the beginning and end of two long strings leaves their middle unchecked. If the page or your capture abbreviates a value, obtain the complete original before recording a match.

Separate labels, filenames and surrounding layout from the value itself. Check the original page if copying introduces spaces or broken lines that make the comparison uncertain. A screenshot can preserve context, but it should not replace a complete, readable comparison record.

Our fictional reviewer, Lina, downloads a reading-club archive and measures its SHA-256 value. The publisher page lists both a Windows archive and a Linux archive. Lina first selects the Windows row because that is the file she saved; the other row's value cannot verify her copy.

Write the result without overstating it

Lina's worksheet records observations and next actions separately. No real archive or publisher is represented in the following cases. These are independent editorial examples of how to keep the conclusion within the evidence.

ObservationAppropriate note
Exact asset and complete value matchSHA-256 matches the recorded reference
Correct asset but values differMismatch; do not mark verification complete
Reference belongs to another assetReference selection unresolved
Only a forwarded hash is availablePublisher reference not established

A mismatch does not identify its cause. Check the asset, version, local path and algorithm before deciding whether another download is appropriate. Do not edit the expected value or select a convenient reference merely to produce agreement.

A match is useful evidence about the measured contents and the selected reference. It is not a malware assessment, an endorsement of the publisher or a guarantee about how software will behave. Retain the source record and make the decision about opening or installing separately.

Questions about download hashes

Can identical filenames replace a hash comparison?

No. The practice exercise shows why labels and contents need separate checks. Record the local path too, so that a result from a different folder copy is not mistaken for the intended measurement.

Can I use a hash sent beside the download?

You can record what the sender supplied and compare against it. Until its publisher origin is established, describe it as the sender's reference. A matching pair from one unverified message does not resolve who supplied the original file.

Does a match mean I should install the file?

The comparison does not make that decision. It addresses the contents relative to the selected reference, while the source, purpose and requested permissions remain separate questions. This article provides no approval for a specific installer or download.

Sources and next checks

The technical facts about Get-FileHash, SHA256 selection, LiteralPath and output fields were checked against Microsoft's Get-FileHash documentation on 18 October 2026. The short explanation of cryptographic hashes uses NIST's hash-function glossary. The reading-club exercise, Lina's comparison worksheet and result notes were independently designed by i8 Live.

Before considering an Android installation, read our separate download and permission checkpoints. To keep a captured reference attached to its original context, use the source and date checklist for screenshots.

Sources