Obtain the intended file and a trustworthy matching reference, compute the documented digest without running the file, and stop on a mismatch instead of treating a matching hash as a safety certificate.
A checksum can answer a narrow question: do the bytes in this downloaded file match the digest you expected? It cannot, by itself, tell you that the expected file is harmless, that the publisher is legitimate or that installing it on your website is a good decision.
Start with the intended publisher, release and reference. Then compare the correct file using the stated algorithm, without opening or executing the download. This guide uses an illustrative download.zip filename; it does not report a download, executed command or verified package.
Decide what you are trying to establish
Imagine a fictional site maintainer downloading an archive for a controlled test environment. The maintainer wants to know whether the local archive matches the publisher’s identified release. That is different from deciding whether the component is maintained, compatible or permitted by its license.
| Question | Useful evidence | What it cannot settle |
|---|---|---|
| Did this file change relative to my recorded copy? | A digest computed and retained from that known copy | Whether the original was trustworthy |
| Does this archive match the intended release? | An exact-file digest from a trustworthy release reference | Whether the release is safe to run |
| Who signed the reference or file? | A signature checked against the correct trusted key | Trust in a key merely because it was downloaded nearby |
| Should this component go on my website? | Source, compatibility, permission and controlled functional review | Everything from a hash match alone |
Writing the question first prevents a common shortcut: calculating any hash and announcing that the download is “verified.” With no trustworthy expected value, the calculation creates a local fingerprint. That can be useful for later change detection, but it is not a publisher-authentication result.
Identify the exact package before looking at its digest
Reach the publisher through a known route, not a sponsored imitation or an unexpected message’s attachment. Record the product, release, operating system, architecture and package format when those choices apply. A ZIP archive and its extracted contents are different inputs.
Keep the downloaded filename and actual path together. A browser may append a suffix when a file already exists, leaving two similar names in the download folder. Do not hash the older copy while reading a reference for the newer one. If the package has several variants, locate the reference for the exact variant selected.
For the fictional maintainer, an acceptance note might name the intended release and archive path before any command is run. It should not copy a real secret download URL into a public issue. Entitlement links, account tokens and private support attachments need a more restricted record.
Establish trust in the expected value
GnuPG’s integrity guidance explains the weakness of obtaining a file and its hash from the same compromised source: both can be replaced. A signature adds a useful link only when the correct signing key and its trust have been established.
Ubuntu’s download-verification workflow illustrates a chain: authenticate the checksum reference, then compare the downloaded image with it. Follow the current publisher’s instructions for your own package rather than copying an old release name, fingerprint or command sequence into an unrelated check.
If a publisher supplies only a digest on its official release page, document that actual boundary. It can help detect a damaged or mismatched download relative to the page, but it is not the same evidence as an authenticated signed manifest. Do not upgrade the claim in your support note.
If the expected value arrives in an unexpected email or third-party forum, find the official reference independently. If no suitable reference exists, say so. A mirror’s convenient checksum may be useful operational information, but it does not become authoritative merely because it matches.
Compute the documented algorithm on the intended file
Microsoft documents Get-FileHash with LiteralPath and explicit algorithm selection. The digest concerns file contents, not the filename. This read-only PowerShell example assumes the illustrative archive is in the current directory:
Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256Check the reported path as well as the algorithm and digest. LiteralPath treats the supplied path literally instead of interpreting wildcard characters. A successful calculation of the wrong file is still the wrong check. Do not run the downloaded archive’s contents to obtain its checksum.
GNU Coreutils documents sha256sum for SHA-256 computation. Where that existing tool is available, an illustrative command is:
sha256sum -- './download.zip'For a checksum manifest whose trust has already been established, the documented check route can look like this:
sha256sum --check './SHA256SUMS'Inspect the complete result and any errors; do not filter the output to only successful lines. The manifest may list files you did not download. Do not substitute a bare cksum command, whose default CRC is a different calculation, or switch algorithms until one result happens to agree.
Compare the complete value and retain the outcome
Compare the same algorithm’s complete digest for the exact file. A few matching opening characters are insufficient. Avoid retyping a long expected value if a supported verification route can compare the authenticated manifest directly.
Keep a small record: package identity, local path, reference location and trust method, algorithm, complete comparison result and date. When a signature is involved, retain the trusted-key verification evidence appropriate to the publisher’s process. Do not label an unresolved warning as a pass.
There is no fabricated expected digest in this guide. The reference must come from the real intended release. A tutorial’s example hash, even if it looks realistic, would be meaningless for the file on your computer.
Stop on a mismatch and find the reason
Do not install or upload a mismatched package to see whether it works. First check for a wrong variant, older duplicate, unfinished download or reference for an archive when you calculated an extracted file. Recheck the exact path and algorithm without changing the expected value.
If you need another download, use the known publisher route again and keep the first result separate for investigation where appropriate. A repeated mismatch deserves clarification from the publisher through its official channel. Do not delete a warning by disabling the check or accepting a digest supplied by an unrelated download site.
A mismatch does not by itself prove an attack; a match does not prove harmlessness. Report the evidence you have. If a package was already executed and there are signs of compromise, use a separate incident workflow, such as our WordPress first-response guide, rather than treating a later recalculation as cleanup.
Keep integrity separate from deployment approval
Once the bytes match the trustworthy reference, the next decision still concerns source, permissions, dependencies, compatibility and rollback. Review a website component in an isolated authorized test environment before changing production. A correctly downloaded release can contain a defect or be unsuitable for the site’s current stack.
Use the SFTP workflow when moving approved files to the intended server, and the third-party component inventory to track why the dependency exists. A checksum is one piece of a release decision, not a replacement for those boundaries.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Microsoft Learn: Get-FileHash, Windows PowerShell 5.1Checked The documented LiteralPath parameter, explicit SHA256 selection and hashing file contents rather than names.
Limits: A computed hash without a trusted matching reference does not authenticate the publisher or establish safe behavior. - GNU Coreutils: SHA-2 utilitiesChecked sha256sum remains documented for computing and checking SHA-256 file digests.
Limits: An unqualified cksum uses CRC rather than being a SHA-256 substitute; manifest verification depends on trusting the reference. - Ubuntu: How to verify an Ubuntu downloadChecked The chain of authenticating the checksum manifest and then comparing the downloaded file.
Limits: The guide uses the chain concept, not older release filenames, keys or command pipelines as a universal current recipe. - GnuPG: Integrity checkingChecked A file and hash from one compromised location can be replaced together; signature verification requires the correct trusted key.
Limits: A signature result does not automatically establish trust in an unknown key, safe execution or freedom from malware; old SHA1 examples are not adopted.