How to Verify File Integrity with SHA-256 Checksums
Learn how SHA-256 checksums verify file integrity, how to compare hashes safely, and mistakes to avoid with downloads and releases.
Quick answer
Compute SHA-256 over the exact file bytes, compare the 64-character hex digest to the published checksum, and treat a match as proof the file is byte-identical — not proof it is malware-free. Use the Hash Generator to hash files locally; use Argon2 or bcrypt for passwords, not SHA-256.
Key takeaways
- ›SHA-256 checksums detect accidental corruption and wrong artifacts; they do not scan for malware.
- ›Compare digests case-insensitively and trim whitespace when copying hex from manifests.
- ›Integrity (checksum match) is not the same as authenticity (cryptographic signature).
- ›Prefer SHA-256 for new releases; use MD5 only for legacy compatibility checks.
Apply this guide with the Hash Generator
Open Hash GeneratorRelease pages, package mirrors, and CI logs often publish a SHA-256 checksum next to a download link. Comparing your local file hash to the published value confirms the bytes match — useful for catching truncated downloads, corrupted transfers, or wrong artifacts. It does not prove the file is malware-free, and it is not a substitute for password hashing.
Use the Hash Generator to compute SHA-256 digests for text and files in your browser.
What is a checksum?
A checksum (in this context) is a fixed-size digest produced by a hash function over file contents. If even one byte changes, the digest should change unpredictably.
file.bin → SHA-256 → a3f2e1... (64 hex characters)Checksums answer: "Did this file change?" They do not answer: "Who published this file?" or "Is this file safe to run?"
Why SHA-256 is commonly used for file integrity
SHA-256 is part of the SHA-2 family and is widely supported:
sha256sumon Linux and macOS- Git object IDs (with additional git formatting)
- Container image layer digests
- npm package integrity fields
- GitHub/GitLab release asset checksums
It produces a 256-bit (64 hex character) digest — compact enough for manifests, strong enough for accidental corruption detection.
How file integrity verification works
- Publisher computes SHA-256 over the exact release bytes
- Publisher publishes the hex digest alongside the download
- You download the file over HTTPS (transport security)
- You compute SHA-256 locally on the saved file
- You compare your digest to the published value character for character (hex is case-insensitive)
If they match, the file you have is byte-identical to what was hashed — assuming the published checksum itself was trustworthy.
Integrity vs authenticity
| Concept | What it proves |
|---|---|
| Integrity (checksum) | File matches a known digest |
| Authenticity (signatures) | File was signed by a holder of a private key |
A checksum on a compromised website could be swapped along with the file. For high-assurance distribution, combine HTTPS, signed releases (GPG, Sigstore, npm provenance), and checksums.
Example: compare a downloaded file checksum
Published manifest:
release-v2.4.1.tar.gz
SHA-256: 8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac8b3298f762301dTerminal (Linux/macOS):
sha256sum release-v2.4.1.tar.gz
# Compare output to manifest (ignore case)Windows PowerShell:
Get-FileHash release-v2.4.1.tar.gz -Algorithm SHA256Browser workflow:
- Download
release-v2.4.1.tar.gz - Open Hash Generator
- Upload the file (or drag-and-drop)
- Select SHA-256
- Compare the 64-character hex output to the manifest
How to use ByteToolBox Hash Generator
- Go to Hash Generator
- Choose text for small strings or file upload for binaries/archives
- Select SHA-256 (default recommendation for new checksums)
- Copy the digest into your ticket, CI log, or comparison notes
Hashing runs locally — file bytes are not uploaded to ByteToolBox servers.
SHA-256 vs MD5 for checksums
| Algorithm | Status for new checksums | Notes |
|---|---|---|
| SHA-256 | Recommended | Expected by modern tooling |
| MD5 | Legacy only | Collision attacks exist — do not use for security-sensitive integrity |
| SHA-1 | Deprecated | Similar legacy status |
MD5 may still appear on older mirrors. You can compare MD5 in the Hash Generator when verifying legacy artifacts, but publish SHA-256 for new releases.
Read SHA-256 vs SHA-512: Which Hash Should You Use? for algorithm choice details.
What checksums can and cannot prove
Can:
- Detect accidental corruption (bad download, disk error, wrong file copied)
- Confirm two copies are identical
- Support reproducible build comparisons
Cannot:
- Guarantee a file is free of malware
- Replace code signing or package signature verification
- Secure passwords (use Argon2, bcrypt, or scrypt instead)
- Prove publisher identity without a trusted signing chain
Common verification mistakes
| Mistake | Fix |
|---|---|
| Comparing hashes of different file versions | Hash the exact published filename and version |
| Extra whitespace in copied hex | Trim spaces and newlines before compare |
| Hashing before download completes | Wait for download to finish; verify file size |
| Using MD5 for new security-sensitive releases | Publish SHA-256 |
| Assuming match means "safe to execute" | Treat checksum as integrity only |
| Using SHA-256 for password storage | Use adaptive password hashes with salts |
Related tools
- Hash Generator — SHA-256, SHA-512, and legacy algorithms for comparison
- Base64 Encoder — encode manifest snippets for tickets or JSON payloads
Try Hash Generator
Compute a SHA-256 digest now with the Hash Generator — paste release metadata or upload a file to verify integrity before deploy.
Related tools
Related guides
SHA-256 vs SHA-512: Which Hash Should You Use?
Compare SHA-256 and SHA-512 for checksums and integrity, how they differ from MD5 and SHA-1, and when each algorithm fits.
HashingWhy MD5 and SHA-1 Are No Longer Secure for Password Hashing
Understanding the security implications of using deprecated hash algorithms and what to use instead.
Base64Base64 Encoding: When and Why to Use It
Understanding Base64 encoding, its use cases, and best practices for web development.